Conan: [feature] Passing dependency version info to conanbuildinfo.cmake

[dbenner]

Summarizing what I'd like to be able to do and where I am stuck:

1) Conan installs dependencies, e.g. zlib/1.2.3, boost/1.70.0, etc.
2) Conan puts the above version info into conanbuildinfo.cmake
3) CMake uses the variables passed in from conan to generate a .h file that documents which external dependencies are used in the build so that the application can display it, save the info, etc.

I am stuck at stage 2, i.e. I could not find a way for Conan to create variables documenting the version info of my dependencies. This is relevant for additional generators, not just CMake.

As per https://docs.conan.io/en/latest/reference/generators/cmake.html#cmake-generator , Conan will create CONAN_\_ROOT, CONAN_INCLUDE_DIRS_\

I would like to have a CONAN_\

---

[memsharded]

Hi @dbenner

Yes, this feature might make sense. It is a bit inconvenient to add it now, so I'd suggest to improve this while we stabilize all the generators (probably the cmake_find_package generators too, not only the cmake one, and other build systems too), for Conan 2.0.

In the meantime, you can access easily the versions of the dependencies and pass them to your build system, something like this:

def build(self):
    cmake = CMake(self)
    for k, v in self.deps_cpp_info.dependencies:
         cmake.definitions["CONAN_%s_VERSION" % k] = v.version

That will pass cmake variables in the command line. Please let me know if this helps.

[dbenner]

Looks like that should do the trick. Will give it a try.
Thanks @memsharded

[dbenner]

Hmmm, partial success. Works on Linux where I just run conan build.

However when developing on Visual Studio (2017), VS calls CMake which uses cmake-conan, so build() never gets called. Here's the Cmake code:

if(NOT CONAN_EXPORTED) 
    # when cmake is called by conan (Linux), dependencies are already installed
    # Otherwise (VS), need to run conan to get/build dependencies

    # https://github.com/conan-io/cmake-conan/raw/v0.15/conan.cmake
    include(conan)

    # Make sure to use conanfile.py to define dependencies, to stay consistent
    conan_cmake_run(
        CONANFILE conanfile.py
        PROFILE ${CONAN_PROFILE}
        BUILD missing
    )
endif()

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup(TARGETS)

That's why I wanted to get the version info into conanbuildinfo, as I just include that file after calling conan_cmake_run().

[memsharded]

That's why I wanted to get the version info into conanbuildinfo, as I just include that file after calling conan_cmake_run().

Ok, I understand, we will try to add it, but it seems challenging before 2.0, lets see what is possible.

What I would like to know more is why you are following a different flow in Linux and Windows, and why using cmake-conan in Win (even if I am the main contributor to cmake-conan I am not a big fan of it). The cmake-conan works when working as a consumer, but in the conan create flow, it will always be the build() method that works (and cmake-conan shouldn't be used at all, it has to be disabled), and it should work the same in all platforms. is it a pure consumer use case?

[dbenner]

What I would like to know more is why you are following a different flow in Linux and Windows

Most development is on Windows/VS, the team has gotten used to doing everything in the studio. As VS only knows how to call CMake out of the box, I was glad to find cmake-conan to bridge the gap to Conan.

I am indeed purely a consumer, not building a Conan package, just consuming others. Not calling create, only install and build. On Linux cmake-conan does not get called.