Best practice for debug/opt/release buildtypes and generating VisualStudio

[GertyP]

A couple of common build use cases aren't especially clear to me regarding how they're best or normally done with meson.

The first is simply hopping between debugging/testing different build configurations like debug/debugoptimized/release.

It seems to me that you could have a top-level 'meson.build' file with just one 'executable(...)' (or 'build_target(...)') element.  Then, to run/debug your debug build, you'd run -
 > meson setup build --buildtype debug
 > meson compile -C build
and then run/test/debug.  If you then wanted to switch to an optimised debug build, you'd run -
 > meson setup build --buildtype debugoptimized
 > meson compile -C build
and then run/test/debug.

Alternatively, it seems as though you could do the following setups once only, all up front -
 > meson setup build_debug --buildtype debug
 > meson setup build_debugopt --buildtype debugoptimized
 > meson setup build_release --buildtype release
leaving you to switch between the build configurations with -
 > meson compile -C build_debug
... test/debug/etc.  And then another -
 > meson compile -C build_debugopt
... test/debug/etc.

However, it also seems like you could have 3 different executables/targets in the top-level 'meson.build' -
    executable('demo_debug', ..., override_options : ['buildtype=debug'] )
    executable('demo_debugopt', ..., override_options : ['buildtype=debugoptimized'] )
    executable('demo_release', ..., override_options : ['buildtype=release'] )
and then you'd just do the setup once only -
 > meson setup build
and then to compile/build before testing/debugging for a particular configuration, you'd do -
 > meson compile -C build demo_debug
or
 > meson compile -C build demo_debugopt

I might have missed something in the documentation but I see no clear guidance on these approaches, which I think would be useful for a more comprehensive example.  So which of these possible approaches is recommended and why (of if there's another preferred alternative, what is it)?

I should also mention that the last approach above means that, if you also generate a VS solution under this scheme, you end up with a solution containing 3 separate projects along with only one 'Debug' build configuration in effect in the solution (I also think it may be an oversight that the override_options for the opt and release 'buildtype's aren't properly set on the 'demo_release' project).  This whole approach almost gives you a single generated sln, within which you have the ability to switch between debug/opt/release builds of the project ... but it's really contorting both meson and VS to arrive at this conventional visual studio set-up of a solution with 1 or more projects and 3 switchable build configurations (Debug/DebugOptimized/Release).


The other question that I can't find clearly covered is this:   Other build systems let you generate visual studio solutions and projects, but in such a way that the project(s) are still configured to compile/build with the external command of the master build system in use.
I.e. instead of the generated .vcxproj being set to use -
    <ConfigurationType>StaticLibrary</ConfigurationType>
or -
    <ConfigurationType>Application</ConfigurationType>
it's set to -
    <ConfigurationType>Makefile</ConfigurationType>
instead, along with populating the project's Properties > NMake > [build/rebuild/clean] Command Line fields with sutiable 'meson ...' commands.

But my interpretation of the way that the meson documentation introduces visual studio generated solutions is that users would use something like -
 > meson setup build --backend=vs2022
which nicely generates a solution and projects ... but it leaves the project configured to compile/link/build with the standard MSVC build system, which is an unusual use case, in my experience:  If I have a comprehensive, clean, fast, self-contained and portable build system (i.e. meson) that's set up for a particular project, then that's what I always want to use to build that project.
It's excellent to have a generated VS solution that matches the master build description/configuration, while still allowing you to run the exact same build steps and machinery across multiple computers without necessarily needing visual studio installed (i.e. running the more portable/consistent/self-contained master 'meson compile -C ...' build command on all machines regardless of whether they've got any or multiple versions of visual studio installed).
This is especially nice if the generated solution and projects also appropriately populate the generated project's Properties > NMake > IntelliSense:  'Preprocessor definitions' and 'include search path' fields, that are appropriate for the projects build configuration.
This approach would leave Visual Studio to do what it's good at (exploring, navigating, refactoring, intellisense, syntax colouring, debugging, etc), while using the better tool for the job of building.
In fact I wonder whether anyone would ever want to use the MSVC build infrastructure in their meson-generated solution/projects over using the original meson builds, since meson is the master build system anyway, with ease of switching toolchains/sdks through native .ini files.  This might also unburden meson devs from having to maintain and fix issues arising from the 'meson to sln/vcxproj' translation phase, if all generated projects are just the 'makefile'-style projects that are set to launch the appropirate meson build commands.

In other words, it looks like meson's generated VS solutions/projects currently also impose the MSVC build system into the generated solution, but it would be far preferable in my experience, to generate VS files so that they're configured to still build with the meson build commands.

You might wonder, "Why not just use the generated VS slns/projects, but build via meson in a command prompt, outside of Visual Studio?":  Well, that would seem to be the next best option available at the moment, but it's not ideal because you want to use the VS keyboard shortcuts to build/rebuild/clean as well as wanting debug/opt/release correct preprocessor defines and includes set up in VS sln/vcxprojs so that intellisense (or VAssist) all work correctly, for which you also would much rather not have to switch between different, separate debug/opt/release-generated solutions when merely changing the optimisation configuration in VS.

Also, in the area of generated VS solutions and projects, but overlapping with the above subject of 'how best to arrange debug/opt/release build configurations" is that Visual studio's usual, normal set-up is to have a solution with one or more projects and an essentially global 'Debug'/'Release' configuration selector, making it quick to switch optimisation configurations when building/testing.  If not already possible (and I've somehow missed it), it seems as though meson is very close to being able to generate a single VS solution (and project(s)), with the multiple debug/opt/release configurations properly added and set up (but again, ideally purely with the the makefile-style VS project, with intellisense include paths and pre-proc. defines set)... which would be really great.  E.g. -
    > meson setup build --vsgenerate=2022
would have an implicit "using all 3 main 'buildtype' values" as VS 'configurations' or you'd explicitly list them with -

    > meson setup build --vsgenerate=2022 --vsconfigs=debug,debugopt,release

So, can meson generate the sln and vcxproj files with multiple 'buildtype's (each becoming a VS build configuration)?  If not, could this be added?

. . .

Miscellaneous bonus

I saw a 'auto_features' built-in option, which, given my aversion to hidden guess/find/flail machinery, is a feature that I quite like the sound of, so I experimented with -

    [built-in options]
    ...
    auto_features = disabled

to see what, if anything, it would affect and require me to explicitly specify.

But I first noticed that the '>meson setup ...' flag seems to be "--auto-features", while the built-in options (https://mesonbuild.com/Builtin-options.html#core-options) docs list it as "auto_features" (note the underscore vs hyphen difference).
Is this difference a mistake or a slightly unfortunate, intentional convention difference?  It just adds a little bit of extra friction or cognitive burden when you can't look at a command line option and know exactly how it'll be used in a native/cross file's [built-in options] section.