search

cps-org / cps

Common Package Specification — A cross-tool mechanism for locating software dependencies
https://cps-org.github.io/cps/
Other
99 stars 8 forks source link

Further clarify and refine search paths #48

Closed mwoehlke closed 6 months ago

mwoehlke commented 7 months ago

This PR is intended to accomplish three four things:

Fixes #45.

dcbaker commented 7 months ago

Can I push back on the /prefix/<name-like> altogether? It seems like an abuse of the file system for CPS files to be littered all over /usr/lib, instead of being tucked into /usr/lib/cps. This would also be a departure from the prior art of Pkgconfig which requires /usr/lib/pkgconfig or /usr/share/pkgconfig, as well as CMake (at least by convention). I can, propose that as an issue if you think that deserves further discussion.

This is clearer, I missed this since it is a departure from pkg-config.

mwoehlke commented 7 months ago

For reference, the new path list looks like:

Added paths are in bold.

(Helps to actually hit the 'comment' button. :stuck_out_tongue:)

mwoehlke commented 7 months ago

Can I push back on the /prefix/<name-like> altogether?

I understand your pain, but I think you may have missed that that is Windows only? The "prefix" on Windows (needs to be determined; see #47) is probably "C:\Program Files", and your best hope for finding anything is going to be exactly /<prefix>/<name-like>, or at least /<prefix>/<name>. Actually, the latter might make more sense, so if you're okay with that, I think we can make that change.

(I'm also somewhat on the fence whether /usr, /usr/local even make sense on Windows...)

mwoehlke commented 7 months ago

Okay, on further thought I'm going to leave /prefix/<name-like> (Windows) alone for now. It makes/made more sense when <name>-* was part of <name-like>, but it's still the only solution we have for co-installs on Windows at this time.

for clarity: <prefix>/share/<name-like>/cps/ is what I'm concerned about.

I am... on the fence. Yes, it would clearly make our lives easier to drop this. OTOH, it's existing practice for projects to want to put their "stuff" in /usr/share/appname. Do we feel confident we can "dictate" that, if you ship a CPS, you must ship it as /usr/share/cps/appname? (Or /usr/<libdir>/cps/appname?) Note that at least wireshark currently ships /usr/lib64/wireshark/cmake/ and might have to be convinced to change.

Meanwhile, I'm going to get working on doing something with #45 here also, and so far I'm feeling like it's good to base those changes on this. Hopefully those will show up soon. (Note: I never intended to merge this without also including those changes; that's why it's WIP.)

dcbaker commented 7 months ago

Do we feel confident we can "dictate" that, if you ship a CPS, you must ship it as /usr/share/cps/appname? (Or /usr/<libdir>/cps/appname?

That is what for example: bash, zsh, pkgconf, vim, and emacs (just to pick a few in my /usr/share) expect you to do. Like the name-* thing, I'd argue that it's better to start conservative, and add more search paths if we find out we really need them.

Just for reference, /usr/share on my machine has 378 directories, /usr/share/pkgconfig has 57 files, /usr/lib has 202 directories, /usr/lib/pkgconfig has 176 files. That triples the number of paths we have to walk for a search. I wrote a python script to recursively walk looking for pkg-config files, when pointed at /usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig that search takes 0.005 seconds, when pointed at /usr/lib:/usr/share it takes 1.5 seconds. That's not reading any files either, that's just identifying files that have a .pc extension.

mwoehlke commented 6 months ago

@bretbrownjr @dcbaker I think this is "final form" now; PTAL. Are we satisfied that: