Skip to content

Problems with cmake build_type variant #6961

@becker33

Description

@becker33

Summary

The build_type variant turns on CMAKE_BUILD_TYPE, which sets optimization flags. Those flags are set after the user-specified CMAKE_C_FLAGS and equivalents. This leads to user flags being rejected under default configurations.

Proposal

Change the default for the build_type variant to "". This is consistent with CMake defaults outside of Spack, and will allow users to specify compiler flags manually without being overridden by CMake. CMake build types can still be specified using the build_type variant.

Positive effects

  • CMake packages will by default respect compiler optimization flags passed by the user.
  • CMake packages will now behave by default as they would outside of Spack by default.

Potential negatives

  • The default build is now less optimized
  • Packages that have set a different default build type in their CMakeLists.txt file will need to override the build_type variant in their package.py file to change the default. (This is actually already true, it just now also applies to packages with default RelWithDebInfo, which was the previous Spack default).

Technical scope

Very small. I have created a PR to change this. #6970

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions