conan: [bug] cmake generator does not write build requirements info when using dual profiles
Environment Details (include every applicable attribute)
- Operating System+version: macOS Big Sur
- Conan version: develop (1.33.0-dev)
- Python version: 3.8.5
Steps to reproduce (Include if Applicable)
With this conanfile.py:
from conans import ConanFile, CMake, tools
class BugConan(ConanFile):
name = "bug"
version = "0.1"
license = "<Put the package license here>"
author = "<Put your name here> <And your email here>"
url = "<Package recipe repository url here, for issues about the package>"
description = "<Description of Bug here>"
topics = ("<Put some tag here>", "<here>", "<and here>")
settings = "os", "compiler", "build_type", "arch"
options = {"shared": [True, False], "fPIC": [True, False]}
default_options = {"shared": False, "fPIC": True}
generators = "cmake"
def config_options(self):
if self.settings.os == "Windows":
del self.options.fPIC
def build_requirements(self):
self.build_requires("doctest/2.3.8")
def source(self):
pass
def build(self):
pass
def package(self):
pass
def package_info(self):
pass
Run conan install . --profile:host=default --profile:build=default
The generated conanbuildinfo.cmake does not contain doctest targets, but it does when conan install . --profile=default is used.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 45 (33 by maintainers)
Hi, @theodelrieu
We’ve been talking about this issue (and related ones) and the path will be as follows:
cpp_infoin plain CMake format. This file will contain the information as plain as possible. It will be hard to define the name of all the variables, but the file will contain information from all the packages in host and build context that are needed to build the package. (Note.- Maybe it is not only one file, but one per requirement, TBD).CMakeDeps(in fact, this generator will use that file/s to populate the targets). GeneratorCMakeDepswill be the recommended (only?) one in Conan 2.0 and we encourage everyone to try it and start using it to smooth the migration.includethat file from theirCMakeLists.txtand will have access to all these variables.find_package_build) or overrides (new definition offind_package) that will help with these scenarios and make it possible some transparent integration of Conan with existing CMake files.There is no ETA for Conan 2.0, it will take some time for sure, not before the end of the year. Discussions happen in the https://conan.io/tribe.html git repo https://github.com/conan-io/tribe
Reasons:
cmake_find_package_multiwhich in turn is an evolution ofcmake_find_package. So CMakeDeps supersed both of them.cmakeandcmake_multigenerators have been heavily criticized by the community for being intrusive and not the cmake way, sofind_package()is the way to go moving forward, and this is the reason those will be removed.Nope! I’ve let dual profiles on the backburner for a few months so I won’t have an enlightenment any time soon 😆.
Cannot agree more.
Any movement on this in general? There is a lot of technical in-depth scenarios which makes it hard to follow whether progress is being made on a higher level. The overarching topic of cross-compiling and use through CMakeDeps and host and build profiles. That mentioned blog post and/or usage documentation would be pretty great about now.
@blackliner I have also had some pretty intense wrestling matches with CMake, Conan, Protobuf and cross-compiling. Don’t mention GRPC… 😄
But yes, it’s the line you mention together with the fact that
find_programin find protobuf prefers the path (PATHS ENV PATH NO_DEFAULT_PATH). https://github.com/conan-io/conan-center-index/blob/master/recipes/protobuf/all/conanfile.py#L127I’m not sure how robust this actually is though… Seems safe to depend on the “looking left to right” fact. Not sure it’s actually safe to depend on the order Conan appends to the path though.
Ok, scratch that, I was looking at the wrong folder. The capnproto_BUILD_MODULES_PATHS_RELEASE is actually empty!
Found it: build_context_build_modules https://github.com/conan-io/conan/issues/7719#issuecomment-848846803
Case closed!
It is not possible to introduce this for
cmake_find_packageas it would be breakingDo you have a better idea? Ideas are welcome!
Not technical reasons, but Conan 2.0 will have only the CMakeDeps generator and we consider we have to stop at some point evolving the old generators to focus on the goal.
The current
protobufrecipe in ConanCenter manages this situation in a very easy way (kudos to the community). Any other code generation tool with the same approach as protocol buffers could implement the same in the recipe and it will work.As it is now, there is no need to modify existing
CMakeLists.txtin projects that are usingfind_package(Protobuf), they will work out of the box, also in a cross-compiling scenario, no need to modify the build-system files to add an extrafind_package.@ericriff Yes, it should be declared when doing the
find_package(my_internal_packageBuild). The issue in general with theCMAKE_PREFIX_PATHusingprotobufas an example, required as build_require and as a regular require at the same time, and also with the multi-config packages, is that the only thing we can do is append all theCMAKE_PREFIX_PATHfor all the configurations and build/host in the same variable because it is not something we can assign to a target, the same issue that we have with thebuild_modules.