Allow a pre-configure step, to allow conan integration

[nolange]

This is a...

• [ ] Bug Report
• [X] Enhancement Request

Allow a pre-configure step, to allow conan integration.

conan is getting increasingly popular and fills some features that arent solveable (in a clean way) within CMake itself.

What I would like to be able:

• Use a layout similar to Mpusz' conan template
• add a new linked folder "build" which points to eg. /tmp/build - which does not exist yet
• upon build, if no "conaninfo.txt" file is existing, then "conan install" is executed first (in the example this will prepare usable zlib binary and headers, and a "conan_paths.cmake" file to be included in the main project)
• only then cmake will be called to configure the build, now finding the prepared libraries and headers.
• build as usual.

Further enhancement would be to forcefully re-run the steps (conan or cmake).

Notes

I know about #91, but this seems to tackle a different issue as I dont want env variables to be set, and the request is specifically about conan. Generalization would be a plus I think, but making CMake + Conan usable in a mostly painless fashion would be most important.

[15knots]

Need more information to make progress on this:

• What/Who is conan?
• What is the requested filesystem-layout? The Mpusz' conan template readme talks of something exiting, which sounds like some phishing attempt to me.

• upon build, if no "conaninfo.txt" file is existing, then "conan install" is executed first (in the example this will prepare usable zlib binary and headers, and a "conan_paths.cmake" file to be included in the main project)

CDT already provides pre-build-steps, wouldn't "conan install" satisfy your needs? IMHO any no "conaninfo.txt" file is existing, then.run "conan install" logic must be handled by conan itself.

• only then cmake will be called to configure the build, now finding the prepared libraries and headers.

That sounds to me like conan is to cmake like what cmake is to make (or `ninja). So why enhance cmake4eclipse? A CDT plugin for conan would be a cleaner option for end-users.

[nolange]

Need more information to make progress on this:

• What/Who is conan?

You could call it an dependency manager, say you need zlib, and one other library that in turn uses zlib. conan would prepare those libraries and make sure there is only one version of zlib. (and there are other nice things like public and private caches of compiled libraries). Unlike CMake's ExternalProject a project just uses find_package, and conan makes sure its available before Cmake is run. See Conan Website, or do a search on conan + cmake.

• What is the requested filesystem-layout? The Mpusz' conan template readme talks of something exiting, which sounds like some phishing attempt to me.

is an opensource github project with a skeleton for conan + cmake (you will find several talks on youtube from Mpusz about the details). nothing more, nothing less, I brought this up as working testcase.

• upon build, if no "conaninfo.txt" file is existing, then "conan install" is executed first (in the example this will prepare usable zlib binary and headers, and a "conan_paths.cmake" file to be included in the main project)

CDT already provides pre-build-steps, wouldn't "conan install" satisfy your needs? IMHO any no "conaninfo.txt" file is existing, then.run "conan install" logic must be handled by conan itself.

that could be easily done by a script, but conan install is similar to invoking CMake, you only do it if its necessary and conan install cant know that.

• only then cmake will be called to configure the build, now finding the prepared libraries and headers.

That sounds to me like conan is to cmake like what cmake is to make (or `ninja). So why enhance cmake4eclipse? A CDT plugin for conan would be a cleaner option for end-users.

Yes, thats debatable. The point is that you share configuration between Conan + Cmake, and to an extend Eclipse. Having 3 settings dialogs for the same thing is unwieldy.

Both need to agree on compiler and targetsystem, conan can build missing libraries from source, which might be a CMake project itself and would need the same settings (CMake Toolchain file, build type) your Plugin uses for invoking CMake. There would be alot to gain to handle both at once.

[15knots]

IMHO it would make much more sense to let CMake handle dependency resolution and place the dependencies in the CMakeLists.txt. When you want to build on your CI-system and have the dependency specified in cmakelists, you do hot have to replicate the deps from the IDE settings again. Just have a look at

• cmake module FetchContent
• hunter https://github.com/ruslo/hunter
• PMM https://github.com/vector-of-bool/pmm (claims to support conan)
• cmakepp https://github.com/toeb/cmakepp/blob/master/cmake/package/README.md (the first I heard of)

[nolange]

IMHO it would make much more sense to let CMake handle dependency resolution and place the dependencies in the CMakeLists.txt. When you want to build on your CI-system and have the dependency specified in cmakelists, you do hot have to replicate the deps from the IDE settings again.

Yes I know of the first 3 of these, and they are way inferior to what conan provides. Some issues that the first 2 have:

• fixed urls/version in CMakelists, which makes using libraries and building offline problematic
• fixed to rebuild from source
• problematic if you have the same dependency multiple times (potentially in different versions)
• unable to transparently use different versions, or your sysroot/system libraries
• running during configure, and unable or highly problematic to use installed cmake config files.

if you use libA and libB, libB beeing a standard CMake project using libA in turn, if you have urls/version in CMakeLists then you would have to adjust the sources libB to use the same version of libA (and ideally not download and build libA twice) conversely, if you take all urls and versions out, a tool like conan could prepare libA and libB in any way you wish. neither the libs nor your projects' CMakelists needs to know as the dependencies are setup before.

If you use PMM or another dropin for conan, it would need would similar support for configuration and prebuild-steps.

BTW, CDT's prebuild steps dont seem to work when your plugin is doing the build.

[15knots]

BTW, CDT's prebuild steps dont seem to work when your plugin is doing the build.

You are right, these only work for the GNU make builder . WTF.

[kutschkem]

#91 could also help here (although working prebuild step would maybe be nicer)

Also, do you know cmake-conan? This is what I use to solve this problem, it calls conan install during cmakes configuration step.

[petermbauer]

Another usecase/problem to consider here: If CMake (and maybe make or Ninja as well) itself is installed via Conan, a script activate.bat which is also generated by conan install in the build directory needs to be called to get the CMake bin folder into the PATH. Under Linux the generated script needs to be sourced. Currently you need to open a shell, source/run the script and then start Eclipse from that shell. It would be much more comfortable if the script would be called by Eclipse itself.

[nolange]

For illustration, there is a plugin for Clion, written about in the Clion Blog.

Whats relevant is that Conan can build missing libraries from source, whether they are themselfes CMake projects or not, and can create a CMake file for your build (again, also if they are not CMake Projects themselfes), that will setup any required paths transparently. settings for CMake and Conan have to match for this reason, and should ideally be managed at one place.

[sliwowitz]

Adding a pre-build step would also allow integrating Spack, a package manager coming from the HPC community. Spack lets you set up an environment with different versions of libraries, and compilers. IMHO, the compiler part is crucial in this case, as it's something that has to be set up before you run cmake, and cannot (or rather should not) be inferred form CMakeLists.txt

I would use something like: spack load cuda && cmake .. when building with nvcc, or spack load [email protected] && cmake .. when trying out a specific Clang version. (the environment has to be loaded bfore running make as well). For my use case, it's similar to the module command from lmod common on most HPC systems.