rapidsai / rapids-cmake

https://docs.rapids.ai/api/rapids-cmake/stable/
Apache License 2.0
27 stars 44 forks source link

[FEA] rapids_cmake_support_conda_env should add `-O0` to debug compile lines #634

Closed robertmaynard closed 3 weeks ago

robertmaynard commented 3 weeks ago

Is your feature request related to a problem? Please describe. When building in a conda env the default CXXFLAGS, CFLAGS, etc will inject -O2 on the compile line making Debug bugs significantly less useful.

Instead of having each RAPIDS project manually handle this issue, rapids-cmake shoudl be extended to do it for users

Describe the solution you'd like rapids_cmake_support_conda_env should be updated to add:

target_compile_options(${target} INTERFACE "$<$<CONFIG:Debug>:-O0>")

That will ensure that debug builds are built without optimizations.

Additional context

When you specify CMAKE_BUILD_TYPE=Debug CMake will provide the -g flag to produce a build with debug information. The optimization level in these cases -O2 is coming from your env ( aka conda ) which globally injects the -O2 along with a host of other optimization flags into CXXFLAGS, CFLAGS. and so forth. This combines together as you have seen.

CMake presumption is that builds occurring under env variables such as CXXFLAGS are explicit requests. Since -O0 is the default optimization level passing -g is sufficient for debug builds and what you wanted was a 'releasish' build with debug info ( aka what CMAKE_BUILD_TYPE=RelWithDebInfo would have done ).

What is the right way to do this?

One argument is that the root issue is the inability to tell conda that you want to do 'debug' builds ( easily ). Therefore the activation scripts should flip the env variables, since conda does establish CXXFLAGS_DEBUG, etc. This solves the problem since it extends outside of RAPIDS. I expect this isn't a viable solution given how long it would take ( if possible at all )

Another argument is that CMake should pick CXXFLAGS etc based on the CMAKE_BUILD_TYPE. Which like the above isn't really possible due to how CMake's compiler detection works. Things like CXXFLAGS are only parsed on the first invocation and are treated as invariant afterwards, while CMAKE_BUILD_TYPE can change for each execution.

Another argument would be that CMake debug flags -g should change to -g -O0 which is more reasonable and would line up with the ongoing discussion around optimization levels in general ( https://gitlab.kitware.com/cmake/cmake/-/issues/23374 ). This again is a long term solution and wouldn't unblock us this year, but I will remember to push on this design going forward.

harrism commented 3 weeks ago

So... what is the short-term solution?

robertmaynard commented 3 weeks ago
target_compile_options(${target_name} PRIVATE $<$<CONFIG:Debug>>:-O0>

Is the recommend solution for targets that want debug info. Since C, C++, and CUDA compilers support -O0 that will map properly no matter the languages used in the target