Multiple targets

[conan-io]

Multiple targets

[traceon]

Just an idea:
in my implementation I use something like this once in the beginning of each directory's CMakeLists.txt:

conan_start_dependency_list()
conan_use(XXXXX)
conan_use(YYYYY)
conan_end_dependency_list()

So conan invocation, conanbuildinfo.cmake generation and inclusion is done in conan_end_dependency_list(), and everything is written in CMAKE_CURRENT_BINARY_DIR. Just need to make sure that conan home and data dirs are properly locked by CMake's file(LOCK ...).

[opilar]

Sorry for my delay. I'll check my case and your suggestions in a couple days and let you know.

[opilar]

@memsharded Yeah. You're right. It's good to me.
Thank you.

[memsharded]

You mean, two CMakeListst.txt, in nested folders, like one being the root? The example code to invoke conan, it should be only in the root CMakeLists.txt of the project. Not sure if I understood your issue, please clarify, thanks!

[opilar]

I have that structure:

├── project1
│   └── CMakeLists.txt # has conan dependency
└── project2
    └── CMakeLists.txt # has conan dependency
├── CMakeLists.txt # includes project1 and project2

[memsharded]

The question is that you can actually build separately project1 and project2, they have their own dedicated build folder, etc, or you have basically one project, with several components, libraries, or apps, called project1, project2, etc.

If you have one project, I would add the conan invocation code in the root CMakeLists.txt, with all the deps.

If you want to be able to run separately both from project1 and project2, and also from the root CMakeLists.txt, I would put the conan invocation cmake code in its separate conan_install.cmake file, and call it from all three. Then I would use some cmake-fu, to just run the conan install the first time. Probably just checking for the existence of conanbuildinfo.cmake before calling conan_cmake_run() could be enough

[traceon]

Well, the lock is not required, unless conan is executed during potentially parallel build-time or multiple simultaneous builds, CMake configuring runs in parallel (not sure if CMake supports this at all), or multiple configuring are started simultaneously.

[memsharded]

Sure, that sounds also an interesting approach. I don't face those issues that much because I tend to do the opposite, every time I have to write "project management" code, I do it in python, which invokes conan and cmake when necessary. So my project is driven by python scripts, not by cmake scripts, I feel it much more convenient and easy to develop and maintain.

[opilar]

The question is that you can actually build separately project1 and project2

No. They are in one repo. Project2 can have project1 as dependency.

You can think of my repo as boost repo: boost-chrono can't be build without boost-system.

The root cmakelist has only add_directory command to include all projects.

If you have one project, I would add the conan invocation code in the root CMakeLists.txt, with all the deps.

You make me list my dependency in one root CMakeLists.txt. It's work the same as conanfile.txt in the root of a repo.

The better idea presented by @traceon.

# project1/CMakeLists.txt content
...
conan_use(XXXXX)

# project2/CMakeLists.txt content
...
conan_use(XXXXX) # we only check for conflict. Do not install the same library again.
conan_use(YYYYY)

# CMakeLists.txt content

conan_start_dependency_list()

add_subdirectory(project1)
add_subdirectory(project2)

conan_end_dependency_list()

That would be better to not have start and end function at all. I don't know if it is possible.

[traceon]

Rationale behind the start()/end() sections in every CMakeLists.txt is that each dir/project may use same libraries which are built differently, with not-so-compatible settings. This is a rare case, but still...

conan_use(XXXXX) # we only check for conflict. Do not install the same library again.

Do we need to check anything? I think conan does a good job by eliminating duplicates, etc. Another pleasant surprise about conan is that it check whether there is a need to (re)build anything very consciously, not just by checking timestamps of config files or full-text hashing. And a run when there is nothing to rebuild is fast enough to even leave one run per conan_use() in CMake configs (although this doesn't seem desirable, due to config variable name clashes.)

[memsharded]

Thats true, I think I would add the cmake conan invocation in each sub-project. If the dependency is listed in the other sub-project with the same configuration, it will not be rebuilt, and it will be quite fast. If it uses a different configuration, then, it might need to rebuild or retrieve from remote. But if you have dependencies between subprojects like Boost, it sounds that the dependency tree would have the same configuration, or you might fall into binary compatibility issues.

[opilar]

or you might fall into binary compatibility issues.

That is what I want to avoid.

Is there any way to check that if some targets have the same conan dependency but with different configuration/options?

[memsharded]

It is not possible, by definition. Conan dependencies in the same tree will have the same settings and options, or it will be an error:

• If the same dependency is used in different paths of the dependency graph (like a diamond), and some configurations is incompatible, the first one will prevail, and a warning will be issued
• The --werror will make such conflicts raise Error instead of warning
• It is possible to have different versions of the same package, with different versions, settings and options if the dependencies are "private", which can only be done in some scenarios, like header-only not in public api.

[memsharded]

Hi @opilar

Reviewing this issue, I still not sure why just adding the conan invocation in the root CMake wouldn't be enough. With the modern cmake targets syntax, I think that sub-projects could just link to the targets they want.

Did you make any progress on this issue? Thanks!

[opilar]

Look at my test example. Two targets have dependency conflict and no warning is given about it.

[memsharded]

From the conan point of view, they are different projects, each one with their own dependencies. Different projects can have different dependencies without any issue, there is no conflict because they are not in the same dependency graph.