[Feature Request] Add 'default' to optimization and debug

[marstaik]

It would be a good idea to add a 'default' option to both the optimization and debug built-in options.

Currently, trying to create custom build-types for certain projects have proven to be impossible due to meson options conflicting with user supplied arguments.

I propose that a default option be added, that does not add any additional optimization or debug flags to the compiler.

e.g.
optimization={default,0,g,1,2,3}
debug={default,true,false}

After going through the mixins, as well as analyzing compiler docs, it seems there is no easy solution.
Each compiler has a different default state, for example some compilers have their default set to zero optimizations, while some have it set to some optimizations. Enforcing that optimization=0 adds zero arguments would create inconsistency between compilers as well.

And maintaining a custom filter list for every compiler would be difficult (e.g. detecting that if a user specifies any /O$ option in MSVC, to remove anything added by meson).

[eli-schwartz]

The general recommendation for linux distro builds where system distributors want to closely control the CFLAGS etc. used, is to use --buildtype=plain, which sounds like the equivalent to what you're suggesting.

Configuring a build directory like that does indeed result in optimization=0 + debug=false... which is, apparently, not what all compilers default to, but I'm not sure whether that's a good thing or a bad thing. Why do some compilers default to passing in some optimizations?

If we added "default", is this something that the plain buildtype should start using?

[marstaik]

Why do some compilers default to passing in some optimizations?

I wish I could answer this question, but as an example, MSVC and Intel's compiler, which use the same flags, have different default behaviors. MSVC will use \Od by default (no optimizations), while Intel's uses \O1 by default, performing some optimizations.

The general recommendation for linux distro builds where system distributors want to closely control the CFLAGS etc. used, is to use --buildtype=plain, which sounds like the equivalent to what you're suggesting.

That may work on linux via gcc and some other compilers, but I looked through the source code and there are many compiler's whose optimization level 0 explicitly passes in arguments (not just WIndows). On some, they can be removed, as they are the default state, but on others they cannot, or we would get different behavior.

As an example, if I set buildtype=plain on MSVC, we currently add in /Od. As a user, if I go to add in /O1, the MSVC compiler will scream about incompatible flags. We already have a hard coded check for \ZI and \Zi conflicts for MSVC, but compilers in general have a lot of conflicting options that we cant forever keep track of.

This is why I propose default be added, where the compilers extra flags are just completely ignored.

If we added "default", is this something that the plain buildtype should start using?

This honestly makes more sense to me than what we are currently using. plain makes sense to me to be the default state of the compiler. It might just be better to rename plain to be default.

As an example, I am trying to port over a complicated build system with tried/true cc/cxx flags, and the maintainers want to have very precise control over the flags. We can kind of do that on linux, because it so happens that optimization=0 and debug=false is the base state of gcc. But not on windows.

Using this allows to also specify the targets unobtrusively through a custom argument, such as target:

if get_option('target') != 'custom' and get_option('optimization') != 'default' and get_option('debug') != 'default'
   # have control for our very specific cc_flags
else
  # the user has specified custom optimization and debug levels
endif

[bruchar1]

Since 0.64, meson now has plain optimization, which doesn't set any optimization flags. I think this addresses this issue. See #10593.