CPS_PATH environment variable behaves differently than PKG_CONFIG_PATH environment variable

[dcbaker]

Concern

$PKG_CONFIG_PATH provides an array of paths to search for .pc files, while $CPS_PATH provides an array of prefixes, with the libdir and datadir rules applied. This is likely to cause confusion for users of pkg-config switching to cps-config or s similar tool.

For example, a current pkg-config command line might look like:

PKG_CONFIG_PATH=$HOME/installs/lib/pkg-config pkg-config zlib --cflags

While the equivalent cps-config command would be:

CPS_PATH=$HOME/installs cps-config zlib --cflags

Proposal

$CPS_PATH should match the semantics of $PKG_CONFIG_PATH, as it is the obvious analogue. A new $CPS_PREFIX_PATH variable should be added in addition, which has the currently speced behavior for $CPS_PATH

Concretely, this means that $CPS_PATH would not apply any libdir or datadir, it would be considered a full prefix and each path would be searched for <name-like>s. A cps-config command of:

CPS_PATH=$HOME/custom-cps cps-config zlib --cflags

Would search:

$HOME/custom-cps/zlib.cps
$HOME/custom-cps/zlib/zlib.cps
$HOME/custom-cps/zlib/*/zlib.cps
/usr/lib/cps/zlib.cps
/usr/lib/cps/zlib/zlib.cps
...

$CPS_PREFIX_PATH would prepend new prefixes to be searched:

sh CPS_PREFIX_PATH="/opt" cps-config zlib --clfags

would search:

/opt/lib/cps/zlib.cps
/opt/lib/cps/zlib/zlib.cps
/opt/lib/cps/zlib/*/zlib.cps
/opt/<share>/cps/...
/usr/lib/cps/zlib.cps
...

Reasoning

Having a CPS_PATH that is analogous to PKG_CONFIG_PATH and sets absolute search directories is useful for non-FHS setups, hand written cps files loaded on the side, and is familiar to pkg-config users. I chose CPS_PREFIX_PATH based on CMake's CMAKE_PREFIX_PATH option, which has the same behavior and is likely to feel familiar to CMake users, and may provide CMake the ability to trivially add prefixes to cps and it's traditional package mechanism

[mwoehlke]

Aside: #44 probably should have bumped the specification version. I'm not going to lose too much sleep given that we're still beating on that area (i.e. this issue, for one), but we should make sure the next change does include a version bump.

[dcbaker]

Okay, I wasn't sure if you wanted to gather up sets of changes and periodically make version bumps, or have a version bump with every change, or every behavior change.

[mwoehlke]

My hope is that, in the long run, changes will be infrequent enough that every change warrants a version change rather than having to adopt a formal release process. Hopefully most of those will be point revisions. For now, breaking changes warrant only minor revision bumps, and the bar for what can be "squeezed into" a point revision is lower.

That said, I'm not opposed to grouping changes if we know we need to change a bunch of things, and certainly anything that gets grouped together in a single branch/PR does not need to change the version every commit.

I'm probably going to add some wording to this effect to the new contribution recommendations. Just to be clear, things like fixing typos, or changes (e.g. the aforementioned contribution recommendations) that don't affect the specification itself (including e.g. cosmetic changes to the specification HTML) don't need version bumps.

And, yes, I expect there's a good chance we'll get to (and pass) 0.100.0. :slightly_smiling_face:

[bretbrownjr]

Adding a PR template to note the need for version bump is cheap.

Adding CI to bump the version or at least reject PRs missing version bumps is affordable too, though we should get the existing CI pull request landed first.