-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support options for backends #429
Comments
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 |
Didn't think about the option framework, it makes sense to put those in there. I don't think these options are recursively applied to subprojects, are they? All |
They are applied recursively for subprojects, in a way. There is only one backend invocation, after all projects have been processed. |
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: So these backends options must be treated differently than user-defined options and be applied recursively, just like Core options ( Proposal: adding a |
Yes, |
I think we should still keep the |
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
ormeson --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?
The text was updated successfully, but these errors were encountered: