-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Generic overrider functionality #3001
Comments
@jpakkane, I'm interested in getting this done sooner than later, so I'm willing to work on it. Do you have a specific format in mind for this? |
There are really only three design requirements:
This would probably need to be some sort of a hierarchical file format. Is INI file sufficient for this? I can't really tell. However one should be able to do at least the following:
A good example for this would be the language standard version. People have expressed requirements to build some subprojects always with Similarly you should be able to override |
This functionality would be very welcome by me after fighting today 2 of the items (not the optimization one) and finding it was not possible to do anything about it :) |
If we go with the "per-subproject builtin options" solution, the only thing missing here is a "per-target options" which could be fixed by adding IMHO, that solution seems easier to implement and rely on existing option infrastructure instead of inventing another file format. |
Actually, I just discovered that we already have override_options kwarg. So per-subproject options is the only thing we miss here. Unless there is something I missed? |
The use case I had in mind (for the generic overrider) was overriding functionality in subprojects without needing to change the build definition files of said subproject. Like suppose a subproject has But thinking about this further maybe it just adds complexity for little gain. You'd still need to test the subproject with your new settings in isolation to make sure it works and then having an extra commit on top starts to look appealing. Dunno. This seems like a difficult design decision. |
IMHO, if the project has shared_library() there is nothing you can do. But if the project has library() then you should have control on the default_library option. |
This is now partially implemented, you can at least override the binaries used in the native toolchain. |
^ Totally agree. It makes sense (and actually a must-have feature) to set per subproject options (e.g. removing |
There are a ton of niggly one-off things people want to do which are reasonable to do but tricky and laborious to do by editing build definitions. Some edits can not even be done because they would touch subprojects. Examples of these include:
All of these should be doable without changing the build definition files. One solution would be to add a Meson switch to read and use a file with these definitions.
The text was updated successfully, but these errors were encountered: