cps files for testing

[tylerjw]

Other than the ones in the tests are there a collection of cps files you've created somewhere for testing this tool?

[bretbrownjr]

No. I was thinking having CPS files for system installed dependencies of cps-config would be a good start. They could be provided for LTS versions of debian, Ubuntu, CentOS, etc.

Initially, we could have smoke tests to validate the installations given CPS files in repo. Eventually, we might build cps-config from meson wraps, then install cps-config in a container, then alias pkg-config to cps-config, then build cps-config again with wraps turned off and using pkg-config workflows.

Of course, we have some code to write to get all that working, but that's a solid "self-hosing" workflow.

Future smoke tests could look like other projects that can or do use pkg-config.

[tylerjw]

Would it be good to work on something that emits CPS files from a build system? (Has CMake already done this?) Then, we could find a collection of libraries written in that build system and have it emit CPS files.

[tylerjw]

Another thing is, should we add support to this tool to specify search-paths through cli arguments instead of always searching in system paths? I would prefer to be able to control where this tool finds cps files without having to make a chroot or container.

[dcbaker]

Eventually, we might build cps-config from meson wraps, then install cps-config in a container, then alias pkg-config to cps-config, then build cps-config again with wraps turned off and using pkg-config workflows.

I've been thinking about this too. But I think the worflow can actually be as simple as:

meson setup builddir
ninja -C builddir test
export PKG_CONFIG=builddir/cps/cps-config/cps-config
meson setup boostrap --wrap-mode=nofallback
ninja -C bootstrap test

This will override Meson into using cps-config as pkg-config, and force meson to find dependencies on the system without using any wraps.

Another thing is, should we add support to this tool to specify search-paths through cli arguments instead of always searching in system paths? I would prefer to be able to control where this tool finds cps files without having to make a chroot or container.

Maybe? We definately need to add support for $PKG_CONFIG_PATH and $PKG_CONFIG_LIBDIR (for pkg-config drop in compatibitility), and the latter of those completely overrides search paths. I opened #45 about this

Another option is, and one we likely want regardless, is a command line option for defining the built-in search paths. Right now it defaults to $prefix/$libdir as defined in Meson, but it seems likely to me that there will be good reason to override that default value.

[bretbrownjr]

@mwoehlke-kitware is working on CMake support for emitting CPS from CMake.

It's possible to write something yourself with a CMake module, I believe, but you'd have to go patch all interesting projects to call an extra command or something.

Some folks have been looking at a good-enough pkg-config to CPS conversion tool. If we want to bootstrap fast in the non-CMake POSIX world (we do), I think that's a good approach. But it also makes sense for build systems to do a best-effort parse of PC files as if equivalent CPS were available.

[bretbrownjr]

Note that the CPS spec supports an @PREFIX@. Also pkg-config supports explicit overrides of the prefix.

Point being, it needs to work that you can put CPS files in ~/.local, for instance, but point at files in /usr.

[dcbaker]

There is a field you can set for that. I’ve written code for that, not sure if it’s landed yet.

[tylerjw]

I've started by making this: https://github.com/tylerjw/ubuntu-jammy-cps

[tylerjw]

Related to 👆 I need a way to set the prefix to be something other than whatever the environment variable CPS_PATH is. It would be nice for testing if I could make a directory of cps files point to system-installed libraries. Should the prefix override be a CLI option, an env variable, an attribute in the cps file, or something else?

[bretbrownjr]

We definitely need a flag. If you look at man pkg-config at --define-variable, they use prefix as the motivating example. To be able to alias cps-config as pkg-config, we will need to be API compatible with that. But a dedicated flag and an environment variable for overriding prefix would be nice too.

[dcbaker]

I think that’s what “cps_path” is for.

[tylerjw]

The problem with cps_path is the CPS files have to be at the same root as the libraries they refers to.

[tylerjw]

It seems this is our current default behavior (from pkg-config man page):

  --define-prefix                         try to override the value of prefix for each .pc file found with a guesstimated value based on the location of the .pc file