[question] cmake_build_modules behavior in conan 1.43.0 and conan 1.43.2

[rajatgirotra]

I am using conan 1.43.2
I have built conan package for google protobuf for my platform using this recipe in conan central.
https://github.com/conan-io/conan-center-index/blob/master/recipes/protobuf/all/conanfile.py
the build recipe sets "cmake_build_modules" in package_info().
self.cpp_info.components["libprotobuf"].set_property("cmake_build_modules", build_modules)

// create command
bash$> conan create . x.y.z@myuser/mychannel -pr debug64 -pr:b debug64

In my consumer conanfile.py, I am using CMakeToolchain and CMakeDeps generators

class MyProjetConan(ConanFile):
    ....
    requires = "protobuf/x.y.z@myuser/mychannel"

    def generate(self):
        tc = CMakeToolchain(self)
        tc.variables["CMAKE_VERBOSE_MAKEFILE"] = True
        tc.generate()
        deps = CMakeDeps(self)
        deps.generate()

I am consuming like this
bash$ /myproject_root/build/> conan install .. -pr debug64 -pr:b debug64

However, the build modules (*.cmake files) aren't set in the generated cmake files with conan 1.43.2

bash$ /myproject_root/build/> grep protobuf_BUILD_MODULES_PATHS_DEBUG protobuf*
protobuf-debug-x86_64-data.cmake:set(protobuf_BUILD_MODULES_PATHS_DEBUG )  # Not Set!!

If I downgrade to conan 1.43.0, then it works.

bash$ /myproject_root/build/> conan install .. -pr debug64 -pr:b debug64  # with conan 1.43.0
bash$ /myproject_root/build/> grep protobuf_BUILD_MODULES_PATHS_DEBUG protobuf*
protobuf-debug-x86_64-data.cmake:set(protobuf_BUILD_MODULES_PATHS_DEBUG "${protobuf_PACKAGE_FOLDER_DEBUG/lib/cmake/protobuf/protobuf-generate.cmake" .... )

Is it a bug or am I using host and build profiles incorrectly? I am building and consuming on the same physical host.

• I've read the CONTRIBUTING guide.

[memsharded]

Hi @rajatgirotra

I am investigating this. I have verified, and you are right, this kind of worked in 1.43.0 but was removed in 1.43.2.

It seems related to the fact that build_modules cannot be defined by component, because they cannot be included by component (it is a global thing per package). It is possible that 1.43.0 was more relaxed about this, but 1.43.2 is requiring a proper definition.

So the protobuf recipe should probably be changed from:

  self.cpp_info.components["libprotobuf"].set_property("cmake_build_modules", build_modules)

to

  self.cpp_info.set_property("cmake_build_modules", build_modules)

I'd need @lasote and @czoido to have a look at this, I don't recall if this was fully intentional and my rationale above is the right one.

[lasote]

I would say it was removed here and I bet it is because we removed the "copy" from the old model ".build_modules" to the new property. It was working because the recipe still have the ".build_modules" and before 1.43 it was being ported to the cmake_build_modules at the root of the cppinfo. So the standalone property at "component" level never worked.

[lasote]

A quick search at conan-center-index reveals that both protobuf/all/conanfile.py and openssl/3.x.x./conanfile.py declares cmake_build_modules property for components. They should be fixed.

[SpaceIm]

Does conan-io/conan-center-index#8820 help?

[SpaceIm]

I'm wondering: since cmake_build_modules should be defined at global scope since 1.43.2, why is it not allowed to define builddirs (injected in CMAKE_MODULE_PATH & CMAKE_PREFIX_PATH) at global scope also when there are components?
I mean, it doesnt make sense to define builddirs per component, it's completly unrelated.

[lasote]

I need to check this a bit more.

[lasote]

I'm going to check why/how could we enable the declaration (not the declaration but the usage at CMakeDeps) of cmake_build_modules property at component level, it might have a sense if you require only a component from a dependency.

[lasote]

it might have a sense if you require only a component from a dependency

It is not possible to do that because the consumer declares the dependency to a component in the package_info, but that is not available at build (generate()) time.

But anyway the linked PR allows declaring the cmake_build_modules property in the components. That is probably less surprising than having to declare it in the root cpp_info properties.