add cmakedeps listening to system_package_version property

[nicosmd]

Changelog: Feature: Add CMakeDeps and PkgConfigDeps generators listening to system_package_version property.
Docs: conan-io/docs#3399

Close: #14789

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[CLAassistant]

All committers have signed the CLA.

[memsharded]

Thanks @nicosmd for your contribution.

It seems there is a gap in the CMakeDeps that is being fixed by #14813. This should follow the same pattern self.cmakedeps.get_property(...), to make sure that the overriding from consumer side also works.

If it is not clear, don't worry, I can try to fix that later. In any case, it would be necessary to add a test that covers it, if you think you can contribute it, great, otherwise, please let me know and we'll contribute it.

[nicosmd]

Hey @memsharded, Ok, I will give it a try to fix it and to provide a test for this feature. Using the test from your PR as a template should make it easier for me. I will let you know if I need help. Thanks!

[nicosmd]

@memsharded fixed the findings. Let me know if you have further feedback.

[memsharded]

Sorry for the delay, it has been some busy weeks.
I am reviewing this, and realized that component_version is used in the PkgConfigDeps context specifically for components versions, not for the package version, so this might not be the best choice of variable. I'll review the goal and alternatives and update, thanks for your patience.

[nicosmd]

Thank you very much @memsharded, let me know when further work is necessary for this PR

[memsharded]

Ok, yes, it seems that component_version would be a bit misleading name, and we would need a different property for this one.
The test is doing a check using the consumer CMakeDeps.set_property(...), but if I understood it correctly, the main use case would be for pkg/system recipes, and then it would be the responsibility of the "system" recipe to detect the system version automatically and define it in its package_info() method? How does this look like? How is it possible to check the version of some system libraries, for example? Do you have some real examples of system library + version + find_package() with specific version number that illustrate the case? What system dependency triggered this in your case? That would help to come up with a property name, something like package_version seems a bit confusing to me, like why would you define this if you already have the self.version which is the version of the package? (yes, for system libraries, but sounds confusing). Thanks very much!

[nicosmd]

Hey @memsharded,

Ok, yes, it seems that component_version would be a bit misleading name, and we would need a different property for this one.

Yeah, I also had the feeling that this might be not the right property. I think I did not made the use case clear enough in the beginning so let me try to answer your questions so we can find a appropriate name for the property.

The test is doing a check using the consumer CMakeDeps.set_property(...), but if I understood it correctly, the main use case would be for pkg/system recipes, and then it would be the responsibility of the "system" recipe to detect the system version automatically and define it in its package_info() method?

This is exactly how I'm currently using it. The system package itself is responsible for setting the property correctly.

How does this look like?

I have created a system package for libalsa, which looks like:

class LibalsaConan(ConanFile):
    name = "libalsa"
    version = "system"
    license = "LGPL-2.1-or-later"
    url = "https://github.com/conan-io/conan-center-index"
    homepage = "https://github.com/alsa-project/alsa-lib"
    topics = ("alsa", "sound", "audio", "midi")
    description = (
        "Library of ALSA: The Advanced Linux Sound Architecture, that provides audio "
        "and MIDI functionality to the Linux operating system"
    )
    package_type = "shared-library"
    settings = "os", "arch"
    build_policy = "missing"
    upload_policy = "skip"

    revision_mode = "scm"

    def build_requirements(self):
        self.tool_requires("pkgconf/1.9.3")

    def export(self):
        git = Git(self, self.recipe_folder)
        scm_url, scm_commit = git.get_url_and_commit()
        update_conandata(self, {"sources": {"commit": scm_commit, "url": scm_url}})

    def package(self):
        pkg_config = PkgConfig(self, "alsa")
        cpp_info = CppInfo(self)
        cpp_info.set_property("component_version", pkg_config.version)
        pkg_config.fill_cpp_info(cpp_info, is_system=False, system_libs=["m"])
        cpp_info.save(os.path.join(self.package_folder, "cpp_info.json"))

    def package_info(self):
        self.cpp_info = CppInfo(self).load("cpp_info.json")
        self.cpp_info.set_property("pkg_config_name", "alsa")
        self.cpp_info.set_property("cmake_file_name", "ALSA")
        self.cpp_info.set_property("cmake_target_name", "ALSA::ALSA")

To be honest, I have the feeling that I am using a bug here as I think component_version should not be applicable to self.cpp_info directly but only to self.cpp_info.components[] but it works for PkgConfigDeps generator. This was necessary since gst-plugins-base for gstreamer which is checking the actual version of libalsa for compatibility and it failed if it was just system.

Do you have some real examples of system library + version + find_package() with specific version number that illustrate the case? What system dependency triggered this in your case?

As I said, I had the error mainly when using the libalsa system package together with the official gstreamer plugin gst-plugins-base package as here it actually failed. But this package is build using Meson + PkgConfig and I mainly raised this issue for consistency reasons. When for meson builds it is possible to make the actual version used from the system transparent to the build it should also be possible for CMake, I think. I'm quite sure that there are cases where the actual used version of a system dependency is required also during CMake builds. This might be relevant for openssl for example. When cross compiling for embedded platforms, I might want to use the openssl library provided by the sysroot, so I create a openssl/system package for it like the alsa example above. Now there are projects which actually validating the openssl version like the Fast-DDS project so it will fail when they are receiving system instead of the actual version of the system. And I expect there are many other use cases for this.

I'm not sure if this feature is only relevant in cross compilation context where it is necessary to work with sysroots. At least this is the case for me so far. Maybe the property name could go in this direction? Like sysroot_package_version?

To be honest, it is also not completely clear to me if this feature is maybe only required for me since I'm workaround the missing feature described in #14566 by creating those system packages and it is not a good idea to add this feature since it wont be useful once a big solution is available. This would depend a bit on when a big solution could become available, I think. But maybe you have an opinion here.

Sorry for the long answer but I wanted to make the use case as clear as possible.

[nicosmd]

Hey again @memsharded,

Some addition: I came across this question by chance #12726, which is exactly what this PR and my question is about. So it seems that there are more use cases for this feature rather then working with sysroots.

[memsharded]

I have finally renamed it to system_package_version, I think the intent and scope is way more clear, and also avoids misuse when the package version is already defined in the recipe, wdyt?

[nicosmd]

I think, that should fit, thanks a lot! One question: As I've mentioned I use 'component_version' property for PkgConfigDeps generator to archive the same goal but my feeling is, that I'm misusing the property for that purpose. Do you think PkgConfigDeps should also get a dedicated system_package_version property?

[memsharded]

I think, that should fit, thanks a lot! One question: As I've mentioned I use 'component_version' property for PkgConfigDeps generator to archive the same goal but my feeling is, that I'm misusing the property for that purpose. Do you think PkgConfigDeps should also get a dedicated system_package_version property?

You are right. I have just added processing of system_package_version in PkgConfigDeps too

[nicosmd]

Thanks, is there something needed from my side to finalize the PR?

[memsharded]

Nop, all good, just merged, it will be in next 2.0.14. Thanks again!!