[develop2] Can conan_provider.cmake work with add_subdirectory

[garethsb]

I have a top-level CMakeLists.txt which has no find_package of its own, it just does add_subdirectory with a second directory (might be a git submodule for example). That second directory contains its own CMakeLists.txt and a conanfile.txt.

If I call CMake at the top-level with -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=.../conan_provider.cmake I have two, related, problems. First, cmake fails because the Conan provider reports there is no conanfile.{py,txt}, and second, if I were to put an empty one at the top-level, I think the Conan provider still won't consider the conanfile.txt in the subdirectory.

I may subsequently have a third and fourth directory each with their own CMakeLists.txt and a conanfile.txt, also added to the top-level project. Or the subdirectory projects may have subdirectories of their own with their own list of dependencies.

Do I have to manually merge the conanfiles at the top level, before calling CMake?

Thanks for help

[garethsb]

Ah, maybe Editable Packages help me here?

[memsharded]

Hi @garethsb

Thanks for your question.
This is something that we should have a look. Certainly, this was not the intended use case of cmake-conan, but to provide a relatively simple way to have single projects calling Conan automatically. But mostly it avoids a conan install call.
If the project is more a meta-project, gathering other subprojects, this seems a bit beyond the original scope of this cmake-conan integration, but lets have a look at it and think about it.

Ah, maybe Editable Packages help me here?

Probably not, those are intended to solve a different problem: working simultaneously on different packages. Something to do occasionally, because mainly using packages means that every package should and will be develop in isolation most of the time (otherwise it is not really a package). But if the project is not really componentized into packages, then the editables won't really help much, and specially they will not provide the same integrated development experience in a single IDE project than a real monolith can achieve.

Regarding the approach of having a meta project with several subprojects and each one containing a different conanfile, consider the following: If those subprojects have dependencies to other subprojects, and they are using different versions of dependencies, things will be ugly, with link errors or runtime errors due to discrepancies. Conan cannot detect those discrepancies of versions, because each subproject has a different conanfile, so they install completely independent dependency graphs, but those graphs are not checked against other graphs computed later in another folder, even if it is a sibling folder.

If you need consistency of dependencies across all subprojects, it would be much better to have a single central conanfile declaring all the needed dependencies. Then each subproject can have different find_package() and link only the ones they need.

[garethsb]

Thanks for the thoughtful response. The use case for me is exactly the one you mentioned of the integrated development experience in a single IDE project, by using add_subdirectory, with the option to switch to find_package when the monolith isn't required, since all the same CMake targets are made available either way.

I do understand the concerns about carefully managing dependencies of dependencies, so a central conanfile when using add_subdirectory maybe the workaround even though switching from find_package would become less simple than just toggling a CMake option.

[memsharded]

experience in a single IDE project, by using add_subdirectory, with the option to switch to find_package when the monolith isn't required, since all the same CMake targets are made available either way.

Definitely, being able to modify the CMakeLists.txt to use some conditional logic to use one approach (find_package()) or the other, would help a lot towards that goal. The thing is that often users expect to be able to switch transparently from mono-repo with add_subdirectory() and just using targets defined in sibling sub-projects, to use Conan and magically have things still working, and unfortunately CMake doesn't allow that that easily.

[garethsb]

I use this idiom frequently:

# Find and use FooBar from its installed location or as a subdirectory
set(USE_ADD_SUBDIRECTORY OFF CACHE BOOL "Use add_subdirectory() rather than find_package()")
if(NOT USE_ADD_SUBDIRECTORY)
    message(STATUS "Using find_package(FooBar)")

    # Using find_package() will require FooBar and its dependencies (Baz, Qux, etc.)
    # to be installed and discoverable via a config-file package or find-module
    # Conan is one way of achieving this...

    find_package(FooBar REQUIRED)
else()
    set(FOO_BAR_DIRECTORY "../FooBar" CACHE STRING "Path to FooBar directory")

    message(STATUS "Using add_subdirectory(${FOO_BAR_DIRECTORY})")
    add_subdirectory(${FOO_BAR_DIRECTORY} build-FooBar EXCLUDE_FROM_ALL)
endif()

[memsharded]

I am adding a test here: #623

that shows that the described add_subdirectory() should work too