search

conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
8.23k stars 980 forks source link

[question] Setting common flags across build types with CMakeToolchain in multi-config generators #15972

Open solarispika opened 7 months ago

solarispika commented 7 months ago

What is your question?

Hi @memsharded

Since adopting the canonical flow (conan install + cmake --preset + cmake --build --preset) per your recommendation in https://github.com/conan-io/docs/issues/3660, I encountered an issue during the CMake configuration step.

To clarify, this seems to be a bug in CMake itself, not in Conan. The commit mentioned in the issue (https://github.com/conan-io/conan/commit/7d93ccc5c77b9c5829162c11b52bdbaaf3e9bcb6) triggers this bug.

The symptom is that after conan installing Debug build type(s), configuring CMake fails to detect the compiler ABI. CMake's attempt to try_compile a test program fails due to a -Werror flag causing the compilation to fail on an unused linker option warning.

I have submitted a merge request (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9377) to CMake to address this issue by filtering out the problematic flags from CMAKE_<LANG>_FLAGS_<CONFIG>, similar to how it's done for CMAKE_<LANG>_FLAGS.

While working on the merge request, I built CMake from source using Ninja Multi-Config, which allowed me to test my changes successfully.

However, this experience led me to wonder if it is possible to assign CMAKE_<LANG>_FLAGS (instead of CMAKE_<LANG>_FLAGS_<CONFIG>) in the CMakeToolchain when using a multi-config generator. There might be cases where users need common flags shared across build types, such as the -Werror flag.

As you mentioned in https://github.com/conan-io/docs/issues/3660, the extra_*flags are considered per-configuration flags, they might not be the appropriate place for such shared flags.

The alternative approach could be to set these flags using cache_variables["CMAKE_<LANG>_FLAGS_<CONFIG>_INIT"] in the conanfile.py. However, this approach also suffers from the multi-config issue, where a later installation overwrites the previous one. Users should be careful not to use different values for these variables.

Could you please provide guidance on the recommended approach to set common flags across build types when using the CMakeToolchain with a multi-config generator? Am I missing something, or is there a better way to handle this scenario?

Have you read the CONTRIBUTING guide?

memsharded commented 6 months ago

Hi @solarispika

Thanks for your question, and thanks for your good research, including the merge request to CMake.

However, this experience led me to wonder if it is possible to assign CMAKE_FLAGS (instead of CMAKEFLAGS) in the CMakeToolchain when using a multi-config generator. There might be cases where users need common flags shared across build types, such as the -Werror flag.

This is a good point. The issue is that the current mechanisms don't have any way to model this, when defining something, from the the profile, command line, everything is tied to the current configuration, because there is no way to differentiate that. Things like tools.build:cxxflags passed in a profile belong to the build_type/configuration of that profile. To be able to make them common to all configurations, we would need something like tools.build:cxx_flags_common, but I'd say this looks a bit ugly.

Conan has mechanisms to share information, so if the same cxxflags are to be used for multiple configurations, it can be reused in its own profile file, and include() from other profiles wanting to use it. If CMake could handle that correctly, that would be the cleanest solution. My understanding is that in multi-config IDEs like VS, there is actually not a common set of flags in a common .props file, but just the same flags that are applied to the different configurations, repeating them.