[bug] Conan 1.37.2 CMakeDeps generator does not bootstrap package's own CMake config file #9112
Comments
|
Hi @SeanSnyders
Library provided config files have two limitations due to CMake:
So in principle, it is not intended that CMakeDeps can defer to such config.cmake files in the packages automatically. A different story is that the self.cpp_info.set_property("cmake_build_modules", ["mymodule.cmake"])Please check also the new variables to activate build_modules in the build context: https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html: build_context_activated, build_context_suffix, build_context_build_modules Please have a look, we will try to reproduce from your repo too. |
|
Hi @memsharded The example (https://gist.github.com/SeanSnyders/30f73a76736864977bd88c0212f55fd7#file-conanfile-py-L34) I gave does enable the build modules in the build context as per the latest documentation: But for your mention of "new properties", there is no documentation on this for
|
|
Further investigation on the current example repro by adding below to the When specifying profiles on the command line (even the same
But when not specifying any profiles (which is essentially the same as specifying the same profile for host and build contexts), then Conan only notes that the target is declared but does not include the external module library.
Overall this is problematic as there is no consistent way to thus include the external library into your CMake project. Can you please try to repro on your side and respond with some further insights and direction? |
|
Delving deeper into Conan's source code and the
|
Hi @SeanSnyders I also have a case where the conan package (hosted in a private artifactory) provides its own config.cmake files. However in that case the package is not a build requirement but a regular requirement of the code being built. Are you saying that the only way to get this "included" is to declare it as a build requirement? In my case conan usage is restricted to a conan install, to retrieve the package, but the rest of the build is driven by calling CMake externally. In a separate project I have implemented a completely conan free technique to get the right version of this package from the artifactory (using curl + aql) but I recently discovered the CMakeDeps and thought that might have less overhead. Regards |
|
@bldrvnlw Things are a bit uncertain and confusing at the moment - mainly due to lack some concrete example documentation (with toy packages as dependencies, etc) and some possible bugs in default behaviour of the feature. Maybe @memsharded can shed some more light, but through my latest experimentation in this issue I do not think it is behaving correctly yet. I believe that setting Best to check the current documentation of this feature and try things out for yourself: https://docs.conan.io/en/latest/reference/conanfile/tools/cmake/cmakedeps.html |
Hi @bldrvnlw Using the internal package xxxx-config.cmake is still possible, that is only restricted in ConanCenter, because you should be aware of 2 main CMake limitations regarding xxxx-config.cmake:
If despite these limitations you still want to use the internal xxx-config.cmake, you can do it, by avoiding the This discussion is mostly about the extra cmake modules that the Please let me know if this helps. @SeanSnyders yes, we know it is still not very clear, we are still heavily working and changing things in all this area, that is the reason the docs are still scarce and confusing. We are trying to stabilize and provide full examples (like conan-io/examples#90) |
|
My use case was very similar and actually used to work... in conan 1.36, but no longer afterward. I built a "Qt5" binary package to put together our own special build of Qt. It's very simple and doesn't describe any components on its own, but rather aims at delegating all the details to the existing I did it that way: def package_info(self):
qt5config = os.path.join('lib', 'cmake', 'Qt5', 'Qt5Config.cmake')
self.cpp_info.set_property('cmake_build_modules', [qt5config])This used to work fine with 1.36, as this build module was loaded and thanks to that, all the logic for the various components was available. However, since 1.37, the build modules are loaded last, so the check for components performed earlier in the generated So my request is the same as Sean's: it would be really great if there was an easy way (like we had in 1.36) to reuse the sometimes complex logic of existing cmake files, as provided by the targeted packages. If there's no particular reason to include the build modules last as it's done now, it would be great to simply move that up. If not, perhaps an alternative group of build modules (silly name: |
|
Hi @SeanSnyders, I've been looking at this, the thing is, the new toolchain generators like A) Modify the documentation with a So, summarizing, you would need to specify the build profile, sorry. |
|
@cboos your issue is totally different. We are evaluating the best way to keep your use case working. I'll report back. |
|
@cboos we are going to move the check later and also will check that the actual complete target exists, not based on the internal |
|
Hi @lasote |
|
Sure. 1=> is a consequence of the missing build profile, the build modules are not assigned. |
|
Hi @lasote I'd like to get back to point 2 from my comment #9112 (comment): Release being generated when Debug build_type is specified for dependencies. I am having issues with this where I specify Debug and have GTest/1.10.0 as a (build) dependency and, as in the screenshot in the previous comment, it generates a mixed situation for GTest. This causes linking failure when trying to link a debug unit test app with the release version of GTest that is picked up / generated by Conan: Running command (even explicitly setting Debug for GTest): Shows these settings and these requirements and note that the package ID for GTest is the Release version even though there is a Debug version on conan-center (https://conan.io/center/gtest?version=1.10.0&revision=5ee038e1d39b4057666e77e49011079e&tab=configuration&os=Windows) for the package. I am confused as to the situation that the GTest conan package contains a Debug version and Conan knows about the different configurations, and the build_type is Debug, so why does Conan not generate cmake files pointing to the right binary package? How should this work? How do I get my situation to work? |
|
If I read correctly, Conan's build_modules is picking up the first installed configuration of GTest.
Looking closer at the output, the Is this a bug? Or what is the logic here? |
Environment Details (include every applicable attribute)
Problem
The new
CMakeDepsgenerator behaviour generates generic CMake*Config.cmakeetc files from the Conan recipes for the external libraries that are specified as dependencies.What if a library provide its own
*Config.cmakefile(s)? It seems that theCMakeDepsgenerator does not defer to that.I would expect the generator to generate the typical files for Conan, but then also still defer/include/execute the package's original
*Config.cmakefile(s).Also, if there is any bootstrapping that needs to occur for said external library and this logic is embedded and shipped with the external library's package, how should that be accessed /executed using the
CMakeDepsgenerator.For past generators like
find_package, it generates aFind<packagename>.cmakefile, but this still had the functionality to include the build module if specified viaself.cpp_info.build_modules[]in the recipe methodpackage_info()for the library.Adding
self.cpp_info.build_modules["CMakeDeps"].append(...)does not seem to make any difference for theCMakeDepsgenerator.Steps to reproduce
Step 1
Clone this repo to get a Conan package (in a sub-folder of this repo) that only contains CMake files that you will install into your local cache.
https://github.com/SeanSnyders/TestExamples.git
Step 2
Then use the gist below that is a recipe that depends on the package above that you installed. This recipe uses the Conan helloworld example as source code, and patches it to suit this test.
https://gist.github.com/SeanSnyders/30f73a76736864977bd88c0212f55fd7
Try to build this package for this gist and it'll fail because it cannot find a CMake utility file that it wants to include that is part of the first package above.
It fails because to illustrate the problem, this dependent library sets a variable
CMAKE_PURECMAKEPACKAGE_PACKAGE_PATHwhich is defined in the library's own CMake config file. Conan does not seem to include this, thus this variable is not defined, and thus the 2nd package could not be built.Logs (Executed commands with output)
Step 1
Step 2
Download gist specified above into new folder, then
Then build and install this package into the local cache
The text was updated successfully, but these errors were encountered: