Make MesonNinja respect the toolchainopts with buildtype as well as --debug and --optimization flags

[Micket]

Fixes #3280
Alternative to #3453

In this version, i double up on both buildtype as well as --optimizationand --debug flags to respect the toolchainopts. I think this will be the better approach, but i haven't tested anything yet.

[Micket]

WARNING: Recommend using either -Dbuildtype or -Doptimization + -Ddebug. Using both is redundant since they override each other. See: https://mesonbuild.com/Builtin-options.html#build-type-options

ok, so apparently meson doesn't want you to do this. I find this strange, as just using the optimization + debug options wouldn't cover things like -DNDEBUG defines. Maybe noone using meson uses such defines in their C/C++ codes? :/

[Micket]

mesonbuild/meson-python#325 No this seems to indicate otherwise. We certainly always want the NDEBUG set for our builds...

edit: see also https://mesonbuild.com/Release-notes-for-0-45-0.html#b_ndebug-ifrelease

[Micket]

Alright, so to summarize

1. I add the -v flag so we can see what we are compiling
2. I set the build type, in case they have some "if-release" logic that adds extra flags and such.
3. I set optimization and debug on top of that, which produces a warning that I disagree with due to the point mentioned above.
4. I set the -bn_debug=true flag for all builds that aren't noopt, so that we get -DNDEBUG when building debugoptimized as well as release. I think by default, the meson-python actually adds the flag -bn_debug=if-release but if we are enabling debug symbols, you don't want to squash this. They mention in the issue tracking n_debug flag that they don't add it automatically to release because they expect packagers to set all their flags themselves anyway.. and i guess they are right (now).

All in all this brings meson builds in line with the rest of the stuff we build, and I don't think any of it is controversial.
Wouldn't surprise me if we see a large speedup in some packages after these changes, but it's hard to test things like "cairo" or "Wayland" for performance.

[Micket]

Test report by @Micket

Overview of tested easyconfigs (in order)

• SUCCESS cairo-1.18.0-GCCcore-13.3.0.eb
• SUCCESS GLib-2.78.1-GCCcore-13.2.0.eb
• SUCCESS libglvnd-1.7.0-GCCcore-13.3.0.eb
• SUCCESS Wayland-1.23.0-GCCcore-13.3.0.eb

Build succeeded for 4 out of 4 (4 easyconfigs in total)
vera-skylake-build - Linux Rocky Linux 8.9, x86_64, Intel Xeon Processor (Skylake, IBRS, no TSX), Python 3.6.8
See https://gist.github.com/Micket/1c22578d1e11a2d81ddd7f38a3c0030e for a full test report.

[Micket]

Test report by @Micket

Overview of tested easyconfigs (in order)

• SUCCESS cairo-1.18.0-GCCcore-13.3.0.eb
• SUCCESS GLib-2.78.1-GCCcore-13.2.0.eb
• SUCCESS libglvnd-1.7.0-GCCcore-13.3.0.eb
• FAIL (build issue) Wayland-1.23.0-GCCcore-13.3.0.eb (partial log available at https://gist.github.com/Micket/b25cd2d50bfff9f3de75fde00bbb16a9)

Build succeeded for 3 out of 4 (4 easyconfigs in total)
vera-skylake-build - Linux Rocky Linux 8.9, x86_64, Intel Xeon Processor (Skylake, IBRS, no TSX), Python 3.6.8
See https://gist.github.com/Micket/d182683aa7be4718a6ad9167888a51d9 for a full test report.

[Micket]

So, Wayland apparently needs to be built with asserts, else it fails the test suite. Which means, one can't actually test a true install... Not sure how much it impacts performance, or if we care about tools like wayland for that sort of performance in HPC settings, so I'm making n_debug into an option.