-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Runtime dependencies #20
Comments
For what it's worth, the inability of pkg-config to describe runtime library search paths in a remotely portable way is a motivating factor for CPS. At least for me. |
Would that mean that CPS file would also be describing binary packages and not just library packages ? So far I understood CPS goal was scoped to the build part, not the later run part. I don't know of many CMake project that exports CMakePackageConfig information for their installed executables. Is there any example to get inspiration ? |
An example is protobuf that exports the |
Yes. It already does this; note the
"Yes", but it's not unusual for a project's build to depend on running a code generator provided by a dependency, and we would like to support that. Qt's To be clear, it is not a goal of CPS to describe how to run an end-user application. It is a goal to enable a consumer that needs to run a dependency's executable as part of the said consumer's build to do so. |
BTW, see #17. (Heh, which predates this...) |
Just adding here, Meson already does this, and some pkg-config files (Qt and wayland-scanner come to mind) do set a pkg-config variable to point to their binaries. I'd like to have this. |
but this isn't quite sufficient - all files required to execute the program need to be explicitly listed e.g. locale files, data files from share directories. |
I think we want the same thing, but I'm explaining what I mean badly. Meson also requires an explicit list of inputs, both the program and any runtime files, or that the running program tell us through a make-compatible depfile what it loaded implicitly. I can actually think of both cases where we need a directory and cases where we need a file (in the directory case, the user is expected to specify the file they want, but the dependency needs to tell us the directory where the file is installed). Wayland-scanner is one where the expectation is that the user tells us what file they would like, but the pkg-config dependency tells us where the files are installed, and then an explicit path is made by combining the two. |
The concept of runtime dependencies seems to be missing from the current spec.
By runtime files I mean anything that a program may load dynamically at runtime but isn't necessarily required at build time. Examples of such things could be dynamically loaded libraries for a plugin eco-system or locale files or configuration files.
I think an end user of a cps file should be able to extract from a linux system all the files required to actually execute something that uses the package that a cps package describes and repackage it (and potentially relocate?) onto another system that doesn't have a system level package installed on it. I'm not suggesting that's a standard workflow but this is what would be required to e.g. build a OCI container containing just a single binary from a derived program that uses the CPS package.
The text was updated successfully, but these errors were encountered: