The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #29960 (depends: pass verbose through to cmake based makefiles by m3dwards)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Ping @hebasto

The defaults for the "Makefile" generator are:

• "RelWithDebInfo" : -O2 -g -DNDEBUG
• "Debug': -g

That differs from our flags, which are -O2 and -O1 -g for Linux respectively.

And CMake can change its defaults at any time (

However, it would be nice to be explicit about the used build type, for example, -DCMAKE_BUILD_TYPE=None.

Right, but a few more things to consider:

An upstream build could be following the docs and doing something like:

# Works correctly for both single and multi-config generators
target_compile_definitions(exe1 PRIVATE
  $<$<CONFIG:Debug>:DEBUG_BUILD>
)

In this case, we wouldn't currently pick up the extra debug opts.

The other thing to consider that is that we could be using
CMAKE_<LANG>_FLAGS_<CONFIG> for these options rather than CFLAGS/CXXFLAGS, potentially overriding the defaults you mentioned above but still being explicit about the build type.

Note that I don't necessarily believe these arguments and don't feel strongly either way, I just wanted to raise the discussion.

i think -O2 -g -DNDEBUG (RelWIthDebInfo) for the release makes sense, it means that the distributed binary will be optimized, with no extra runtime checks, but still get (as far as possible) descriptive debug information such as line numbers and symbols in case it's necessary for troubleshooting, getting a traceback, figuring out where some crash address comes from, and so on.

Edit: Oh, to not forget, debug metadata is also useful to figure out the details of differences between guix-built binaries, like where do they exactly come from. This is what i tend to most often use it for.

🐙 This pull request conflicts with the target branch and needs rebase.

This "seems" like the right thing to do, but I'm also not sure. Could you rebase here, to incorporate other recent CMake changes, and so it's easier to test?

We seem to have gravitated towards using DCMAKE_BUILD_TYPE=None + our flags for CMake packages in depends, (except for libevent), so maybe that is the best thing to do here, for now?

We seem to have gravitated towards using DCMAKE_BUILD_TYPE=None + our flags for CMake packages in depends, (except for libevent), so maybe that is the best thing to do here, for now?

I think this approach is quite straightforward and gives us full control on optimization/debug flags.

To be clear, I was not saying to not make this change, but we could set the None build type globally in both cases.