Enable NDEBUG by default in release builds?

[jhasse]

#1896 adds a new option for b_ndebug that would automatically define it for release builds. There's also some discussion if this should just be the default, but the PR doesn't touch that, so I thought that discussion could be continued in its own issue.

Summary:

• It's also what CMake does
• NDEBUG is a C/C++ standard
• Would make Allow value 'if-release' for b_ndebug project option. #1896 obsolete (or build upon it)
• Some distros don't like it enabled by default; why?

[polarina]

I'd imagine most distros use the plain build type and specify their own build flags. Changing the default behaviour of release builds thus shouldn't affect them.

[nirbheek]

I would be in favour of this.

[SoapGentoo]

This changes what most people would expect, namely that release binaries don't contain any assert()s anymore, so I am very much in favour of this too.

[phillipjohnston]

Except... there are many people who also keep assert() enabled in release builds.

[phillipjohnston]

I guess, however, I fall into the "plain" camp and pick my own flags in this case.

[mattip]

Except... there are many people who also keep assert() enabled in release builds.

@phillipjohnston could you elaborate? What projects want assert() enabled in release builds?

I guess the issue boils down to the vision of meson: does it want to be like autoconf (a low-level, roll-your-own Makefile generator) or like CMake/QMake/python distutils (a higher-level tool to help library developers get their work done with reasonable defaults).

[phillipjohnston]

Before I spend my time, is this comment a real request for my insight? The "What projects" seems combative enough - as if I could name them all. How many examples would satisfy you?

The Pragmatic Programmer included "Leave Assertions Turned On" in 1999, I am hardly the only person with this idea.

[mattip]

Since 1999 much has been learned. One thing that has thankfully become more accepted is that default values should reasonably help users, where the feeling used to be that defaults should provide a minimal experience. I don't think meson should prevent setting/unsetting values, but the question is what defaults should be provided out of the box.

is this comment a real request for my insight?

Yes. I see across the build-tool landscape that -DNDEBUG is an accepted default for release builds. I am curious about C/C++ projects that prefer to keep asserts in release code: how do they then provide a debug experience? Do they have an different mechanism (#if _DEBUG ...)?

[eli-schwartz]

A more interesting question to me, personally, is:

Considering this can be controlled in

project(..., default_options: ['b_ndebug=...'])

Projects that dislike the meson default can always choose which approach they prefer. The downside of this is they have to know it's an important consideration to have.

So, which one is a better default? Should the people that like release assertions have to know they need to configure them, or should the people that hate release assertions have to know they need to configure them? I genuinely don't know the answer to this. :)

[eli-schwartz]

And can we change the default without making people complain that it's a breaking change in a semver stable release of meson? For comparison, when it came to run_command with the check: kwarg defaulting to false, we just spammed everyone with a warning that the current default is bad and they should manually specify what they want. On the other hand, you can't fix run_command without editing the build files, but people who want the assertions back can just pass arguments to meson setup. So this is another question I genuinely don't know the answer to.

When coordinating meson 2.0 we should do what we've been threatening to do for a while, and drop the warning but make check: true the default instead.

... I think that there are far more projects which add a compiled language without specifying b_ndebug, than there are projects which use run_command

[mattip]

Maybe the ship has sailed and this should be turned into a documentation/education issue.