Generic overrider functionality

[jpakkane]

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:

• changing the build type of some target to be shared or static
• change optimization level of one target (because, for example, compiler bugs)
• install or not install files from a given target or an entire subproject
• etc

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.

[dcbaker]

@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?

[jpakkane]

There are really only three design requirements:

• must be human readable
• must be human writable
• should be some file format we already know how to parse if possible

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:

• set the default value for an option
• override the value of an option for all subprojects
• override the value of an option for a specific subproject
• override the value of an option for a specific target in a specific subproject

A good example for this would be the language standard version. People have expressed requirements to build some subprojects always with gnu99 or somesuch regardless of what the superproject uses.

Similarly you should be able to override shared_library, static_library and library (at least) to instead build some other kind of library type.

[germandiagogomez]

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 :)

[xclaesse]

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 library(..., default_options:['optimization=0']).

IMHO, that solution seems easier to implement and rely on existing option infrastructure instead of inventing another file format.

[xclaesse]

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?

[jpakkane]

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 shared_library(...) but you, for whatever reason, would want it to be static_library(...) so you could change it with an override file only and the original code remains immutable.

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.

[xclaesse]

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.

[dcbaker]

This is now partially implemented, you can at least override the binaries used in the native toolchain.

[TheQwertiest]

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.

^ Totally agree. It makes sense (and actually a must-have feature) to set per subproject options (e.g. removing Werror), but changing something inside said project is just a dirty hackery and should not be encouraged or allowed. If the project was never designed to be built as a shared_library it makes no sense to allow replacing static_library with shared_library.