Make Conan optional

[JohelEGP]

I can avoid using Conan with just a few lines of pure CMake:

include(FetchContent)

FetchContent_Declare(range-v3
    GIT_REPOSITORY https://github.com/ericniebler/range-v3
    GIT_SHALLOW True)
FetchContent_Declare(fmt
    GIT_REPOSITORY https://github.com/fmtlib/fmt/
    GIT_SHALLOW True)

FetchContent_MakeAvailable(range-v3 fmt)

At the moment, I have to replicate the logic of src/CMakeLists.txt:

FetchContent_Declare(mp-units
    GIT_REPOSITORY https://github.com/mpusz/units
    GIT_SHALLOW True)

FetchContent_GetProperties(mp-units)
if(NOT mp-units_POPULATED)
    FetchContent_Populate(mp-units)

    add_library(units INTERFACE)
    add_library(mp::units ALIAS units)
    target_compile_features(units INTERFACE cxx_std_20)
    target_compile_options(units INTERFACE -fconcepts)
    target_link_libraries(units INTERFACE range-v3::range-v3 fmt::fmt)
    target_include_directories(units INTERFACE
        ${mp-units_SOURCE_DIR}/src/include)
endif()

[mpusz]

I do not believe that CMake is, or will ever be, a good solution for dependency management. On the other hand, everything looks like Conan is the best way to go as of now. I do not believe vcpkg will prove in the long run for corporations and will only stay as an alternative solution to Conan for small OSS projects.

This is why I do not want to overcomplicate the repo code in a way that will make Conan usage harder. I have a solution in mind that hopefully addresses your needs. If not, please let me know.

[JohelEGP]

Turns out that defining conan_init as empty beforehand does the job:

FetchContent_Declare(mp-units
    GIT_REPOSITORY https://github.com/mpusz/units
    GIT_SHALLOW True)

FetchContent_GetProperties(mp-units)
if(NOT mp-units_POPULATED)
    FetchContent_Populate(mp-units)
    macro(conan_init)
    endmacro()
    add_subdirectory(${mp-units_SOURCE_DIR}/src ${mp-units_BINARY_DIR})
endif()

[mpusz]

conan_init is my utility function defined in a repository submodule. You should not have to redefine it because it uses Conan only if Its files are found. I believe that the change I did (using Conan targets only if they exist) was the proper solution and enough to make you roll.

[JohelEGP]

Yes, now it's working without redefining conan_init. I'm not sure why it didn't work for me before.

[correaa]

I am using this

FetchContent_Declare(mp-units
    GIT_REPOSITORY https://github.com/mpusz/units
    GIT_SHALLOW ON)

FetchContent_GetProperties(mp-units)
if(NOT mp-units_POPULATED)
    FetchContent_Populate(mp-units)
endif()
add_subdirectory(${mp-units_SOURCE_DIR}/src)  # provides mp-units::mp-units
...
target_link_libraries(my_target PUBLIC mp-units::mp-units)

I understand the comment about CMake not replacing conan, however CMake can be made more friendly to FetchContent by using this rather simple technique https://www.foonathan.net/2022/06/cmake-fetchcontent/.

I guess you don't want to encourage using FetchConent in the first place.
But this is just a little step away from https://mpusz.github.io/units/usage.html#copy-cmake

(Anyway, I have to learn how to use conan, specially if it can be done from CMake.)

[mpusz]

Thanks for sharing!

Yes, I don't want to encourage FetchContent as even CMake key developers claim that it is not a good solution for package management. See https://youtu.be/wULu83jQmIQ?t=3262.

(Anyway, I have to learn how to use conan, specially if it can be done from CMake.)

Yes, it can be done from CMake, but it is not the right way to go. This is not only my personal experience but also Conan authors claim the same. Package managers should run on top of build systems and not the other way around.