search

cps-org / cps

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

Runtime dependencies #20

Open jsharpe opened 8 months ago

jsharpe commented 8 months ago

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.

bretbrownjr commented 8 months ago

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.

daminetreg commented 8 months ago

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 ?

traversaro commented 8 months ago

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 protobuf::protoc target, as it is used in downstream projects for code generation (see https://github.com/protocolbuffers/protobuf/blob/5f146f8dfefd136eb969ed3bb73bdd95a462c4f3/cmake/install.cmake#L490).

mwoehlke commented 7 months ago

Would that mean that CPS file would also be describing binary packages and not just library packages ?

Yes. It already does this; note the executable target Type. However, right now we don't always have enough information to actually run such a target. This issue is a critical step toward fixing that.

So far I understood CPS goal was scoped to the build part, not the later run part.

"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 moc and Protobuf's protoc are probably the two best-known examples, but they aren't unique.

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.

mwoehlke commented 5 months ago

BTW, see #17. (Heh, which predates this...)

dcbaker commented 5 months ago

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.

jsharpe commented 5 months ago

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. Bazel / Buck / Pants build systems all require explicit lists of all input files, not just a directory or path which many solutions currently do.

dcbaker commented 5 months ago

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.