Support options for backends

[nioncode]

I'd like to propose a new feature: supporting options for specific backends.

It is common for Visual Studio projects to be compiled with different platform toolsets, target platforms, or target architectures. These can be set in the project files with simple directives like <PlatformToolset>xyz</PlatformToolset>.

These settings can be defined at configuration time so that they can be put inside the project files to make builds from the IDE just work. Or they can be specified when actual building the project with msbuild proj.sln /p:PlatformToolset=xyz, which is what I currently do.

I don't know how those settings can be set with the ninja backend. Probably you'd have to manually set compiler flags and such? That's why I think it makes more sense to introduce backend specific options.

Something like: meson --backend vs2010 --backend-opt PlatformToolset=xyz --backend-opt TargetArch=abc or meson --backend vs2010 --backend-opts PlatformToolset='xyz';TargetArch='abc' Maybe argparse does even provide a simple way to parse such options into a map.

Is this something meson wants to support?

[jpakkane]

Something like this has been planned. The actual implementation should use the option framework that is already there. The idea is that options are prefixed. Plain C compiler options start with c_ and correspondingly Ninja options should start with ninja_, VS options with, say, vs_ and so on.

[nioncode]

Didn't think about the option framework, it makes sense to put those in there. I'd say that meson should reserve all options starting with known prefixes and issue an error (or at least a warning) in case an unknown option is set (like vs_unknown). Note: I just checked the code and meson already does this :)

I don't think these options are recursively applied to subprojects, are they? All vs_options I can currently think of must be the same in all subprojects, just like compiler flags (as they in fact control some compiler flags).

[jpakkane]

They are applied recursively for subprojects, in a way. There is only one backend invocation, after all projects have been processed.

[nioncode]

Test case 50 explicitly uses the same option in the main project and a subproject, which has a different default value in both, which leads to two options being defined: opt and subproject:opt.

So these backends options must be treated differently than user-defined options and be applied recursively, just like Core options (buildtype etc.) and Compiler arguments (c_std).

Proposal: adding a backend_options dict to CoreData and displaying those as Backend options in mesonconf.

[jpakkane]

Yes, backend_options makes sense. There's only one backend at any given time so no need to have several reserved prefixes.

[nioncode]

I think we should still keep the vs_ and ninja_ prefixes instead of (or in addition to) a single backend_, since each backend might support different options. Having separate prefixes makes it clear to users which option is supported for which backend.