[feature] conan2 Use cmake-file-api to get all the project targets info?

[bog-dan-ro]

In conan 1.x cmake projects with multiple targets are not very easy/nice to write recipes for (check vorbis, mpg123, etc.). It will be great if conan 2 can use cmake-file-api to get all the info for that project.

• [X] I've read the CONTRIBUTING guide.

[memsharded]

The cmake-file-api has already some code inside Conan, but it hasn't been made public yet, but you can have a look to the codebase. The reason is that it is not very complete, so a lot of information still need to be provided by users and that makes it confusing. And it doesn't seem to be getting enough attention, so we doubt it will mature enough to be complete anytime soon.

I'll add it to the 2.X pool to revisit once 2.0 is out

[bog-dan-ro]

I'd like to take a look to it, Is this https://github.com/conan-io/conan/blob/develop2/conan/tools/cmake/file_api.py the right one?

[memsharded]

Yes, that one. The idea is to create an intermediate json representation format.

[bog-dan-ro]

Yes, that one. The idea is to create an intermediate json representation format.

I was thinking to something a bit more straightforward (easier?).

Instead to do:

            def build(self):
                file_api = CMakeFileAPI(self)
                file_api.query(CMakeFileAPI.CODEMODELV2)
                cmake = CMake(self)
                cmake.configure()
                reply = file_api.reply(CMakeFileAPI.CODEMODELV2)
                package = reply.to_conan_package()
                package.save()
                cmake.build()

            def package(self):
                cmake = CMake(self)
                cmake.install()
                copy(self, CppPackage.DEFAULT_FILENAME, self.build_folder, self.package_folder)

            def package_info(self):
                cpp_package = CppPackage.load(CppPackage.DEFAULT_FILENAME)
                cpp_package.package_info(self)

I'll do:

            def build(self):
                file_api = CMakeFileAPI(self)
                file_api.query(CMakeFileAPI.CODEMODELV2)
                cmake = CMake(self)
                cmake.configure()
                cmake.build()

            def package(self):
                cmake = CMake(self)
                cmake.install()

            def package_info(self):
                file_api = CMakeFileAPI(self)
                file_api.set_package_info()

Or even easier:

    def layout(self):
        cmake_layout(self) # does all the CMakeFileAPI magic

    def package_info(self):
       cmake_package_info(self) # uses the CMakeFileAPI to setup all the stuff

[memsharded]

I agree that some parts of the current api can be simplified. But hiding it too much is not good either, as always, "explicit is better than implicit". Reading a recipe it should be more or less understandable what is happening.

It is also critical to make explicit the intermediate json output, that decouples the origin from the actual package information, this feature will not happen without it.

[ashley-b]

Are there plains to make this available in Conan 2 ? I've made use of it in a conan 1.x recipe's and find it extremely useful for complex CMake project with many configuration/components

[memsharded]

Hi @ashley-b

We have already started to do some preparation of the basic CppInfo and its json serialization that would help supporting this use case, having it in mind.

Recovering the cmake-file-api is not a high priority, but being in the 2.X milestone means that it is in our roadmap/plans.

[Adnn]

Hi @memsharded

Support for mechanically generating package_info() content from CMake package config files is one of the two features that would really take Conan 2 to the next level in our workflow. (We really do not want to duplicate this configuration description).

I'd like to take a look to it, Is this https://github.com/conan-io/conan/blob/develop2/conan/tools/cmake/file_api.py the right one?

It seems this link to a file in develop2 branch is now dead. Could you please update this link?

[memsharded]

Hi all,

The efforts of using CMake file API have shifted to using the CPS standardization proposal wip, in which we are actively involved, as well as Kitware, Bloomber, Microsoft, etc. See https://github.com/conan-io/conan/pull/16054. Also we did a talk about it last year in CppCon and we will have another talk about it this year in CppCon.

[Adnn]

Hi @memsharded,

Just watched last year video, which was a great introduction to Common Package Specification.

CPS seems to be the way forward with the issue of mechanically extracting the "package info" from CMake-generated package confi. Is there a dedicated issue for CPS related discussions in Conan?

I might be interested to explore this a bit further, which raised a few questions questions already:

• In addition to producing CPS description, will Conan be able to consume them?
  • If so, is there any existing code in some Conan branch to leverage consumption?

But this issue about CMake file-API may not be the right place.

[memsharded]

Hi @Adnn

yes, I think you need to watch this year talk too, the moment it is live: https://cppcon2024.sched.com/event/1gZew/common-package-specification-cps-in-practice-a-full-round-trip-implementation-in-conan-c-package-manager

So we already have in Conan some functionality that loads CPS files created by build systems, it was integrated in last release and we demo'ed it live in CppCon, reading CMake generated CPS files. It is still a but too early to release or document it, but if you are interested, you can look for CPSDeps and cps in the Conan code.

We keep heavily investing into more CPS-compatible functionality, and the new CMakeDeps generator in https://github.com/conan-io/conan/pull/16964 is getting more and more close to CPS conventions (default_components, location and link_location, languages, etc).

So I am closing this ticket as not planned, even CMake is also investing in this way more than in the cmake-file-api, so this totally seems the way to go.

Thanks for the feedback!