fortran-lang
Consume and export Common Package Specification
Description
https://cps-org.github.io/cps/
The Common Package Specification (CPS) is a mechanism for describing the useful artifacts of a software package. A CPS file provides a declarative description of a package that is intended to be consumed by other packages that build against that package. By providing a detailed, flexible, and language-agnostic description using widely supported JSON grammar, CPS aims to make it easy to portably consume packages, regardless of build systems used.
Exporting CPS files would make it easier for other projects to link against libraries built with fpm, while consuming CPS files would allow fpm to link against (already built and/or installed) libraries built with other tools.
Possible Solution
No response
Additional Information
No response
Are you aware of any packages which already use this mechanism? I know that CMake 4.0 was recently released. Is CPS part of it?
I think I've mentioned CPS on Discourse or fpm issues/discussions before but I failed to find the thread.
Edit: yes, it looks like this is now part of CMake 4.0: https://cmake.org/cmake/help/v4.0/command/find_package.html#cps
No, but I think it's a bit of a chicken-and-egg situation -- nobody's likely to start using it until there's good support. Getting support into fpm will be good motivation for people to start using it
I think the CPS schema is a bit under-specified when it comes to exporting pre-built Fortran packages. Something would need to be done about the Fortran modules and submodules which are vendor specific.
Consuming CPS packages of C and C++ projects seems like an easier way to get started.
Kitware published a blog post some weeks ago: https://www.kitware.com/navigating-cmake-dependencies-with-cps/
(cc @mwoehlke)
Wouldn't they just come under includes? Or are you thinking of something else?
I mean if you would run a hypothetical $ fpm --export-cps and it created the binary artefacts (archive, .mod) files and package.cps file, the artefacts are specific to the particular Fortran compiler in use (vendor-specific ABI), and potentially even depend on the compiler flags -r8 -i8 (bad practice!).
So the CPS meta-data schema would need fields to describe this stuff.
Ah, I see what you mean. I think that could in principle be handled by configurations, but that's maybe not so ideal. I think this is supposed to be handled by "single package, multiple platforms", which encourages having separate CPS files for each platform. Given that built artefacts for multiple compilers (and/or build options) cannot live in the same directory, I don't think this is actually an issue. An individual build of a project would generate a single .cps file, it's just choosing how to install this where choices would have to be made.
For C++, there are cpp_runtime_vendor and cpp_runtime_version entries. The Fortran runtime would also need to be captured, possibly in addition to the C++ runtime, so that definitely would need new entries in the metadata schema.