Meson: subproject default options are overriden by parent project's default options

[nirbheek]

This is problematic because, for example, it overrides the c_std value which can cause the subproject to fail to compile. This is a problem in gtk+/glib because gtk+ uses c99 and glib uses gnu89. In this case the workaround is to use gnu99 in gtk+, but not all projects can do this.

[jasonszang]

Also encountered this problem, with werror=true set in master project making one subproject fail to compile and cannot change that subproject to werror=false. Overriding it with default_options in subproject() does not work, and there seems not to be a way to meson configure options in a subproject.

[strassek]

I'm seeing this issue on 0.44.0, hitting compile errors when building SDL2 with a parent project that sets c_std=c11.

[jpakkane]

This is not overridable because (in any language other than C and sometimes even with C) different language versions have different ABIs and can't be linked together. Thus we need to enforce one standard over them.

For the specific case of SDL2, if it does not compile with c11 that sounds like a bug in the code that should be reported and fixed.

[inigomartinez]

This is not overridable because (in any language other than C and sometimes even with C) different language versions have different ABIs and can't be linked together. Thus we need to enforce one standard over them.

Although this is true, the problem with not able to set the default options also extends to those options that are not related to the language standard used.

I have just opened a new issue (#2992) that is slightly different to this one because in that case I wanted to set subproject's options from the parent. Specifically, the issue has arised due to the incapacity of choosing the type of library to be built , static or shared, by using meson's default_library option.

As said in that issue, a new user option can be used as a workaround, but it's rather confusing to duplicate an existing feature.

[mcatanzaro]

This is not overridable because (in any language other than C and sometimes even with C) different language versions have different ABIs and can't be linked together. Thus we need to enforce one standard over them.

This is not really true. E.g. GCC had an ABI break when transitioning from C++98 to C++11, but not from C++11 -> C++14 nor from C++14 -> C++17. And that was managed by distributions when compiling libstdc++, to ensure all code transitioned to the new ABI version at the same time regardless of the language standard being used.

I'm not aware of any ABI breaks required by C language version changes.

Consider an application like Epiphany. It's written in C11, but links to glib (C89) and WebKit (currently C++14, but it was briefly C++17 for a few months). Applications don't need to know or care about the language standard used to compile their dependencies. Nothing would work on Linux desktop if they did.

I suppose mixing language standards in the same static library might not work? Not sure.

Anyway, unless this behavior changes, I'm not sure what else we can do other than stop using meson subprojects. E.g. in https://gitlab.gnome.org/GNOME/glib-networking/issues/60 we use C11 for glib-networking, which has a broken subproject to build glib, C89. Surely this would work fine if meson built the glib subproject with C89. Our only plausible solution, unless Meson were to switch to C89 for building glib, is to require that glib be a system dependency instead of a subproject.

[xclaesse]

I made this PR to support per-subproject built-in options: https://github.com/mesonbuild/meson/pull/4157. I think we definitely need to make at least c_std and default_library per-subproject. More options could be added per-subproject on a case-by-case basis when someone has a valid use-case for it, or we could just make them all per-subproject after all...

[Snaipe]

Another issue I've recently faced: I have a library that rely on a symbol being either 1) resolved at runtime by the dynamic linker if it is a shared library or 2) resolved at link time if it is a static lib.

This is currently achieved with 'b_lundef=false' being set in the default options of the project, and without it the project cannot compile as a shared lib. However, when it's used as a subproject, not only does it default to a shared lib build, but also sets b_lundef back to true, breaking the shared lib build.

I had to change the dependency to only build static libs in the meantime, but being able to specify defaults that don't break to the subproject options would be great.

[nirbheek]

This was fixed for default_library in https://github.com/mesonbuild/meson/pull/4157. That fix is in 0.54: https://mesonbuild.com/Release-notes-for-0-54-0.html#per-subproject-default_library-and-werror-options

The generic fix will be https://github.com/mesonbuild/meson/pull/6597 I believe?

[xclaesse]

There is no generic fix, for each option we want to make per-subproject we have to fix each place that option is accessed in Meson. For compiler options I started working in https://github.com/mesonbuild/meson/pull/6729.

[dcbaker]

Right, #6597 just makes it easier to set a huge array of complex options.