Meson: Have the equivalent of AX_COMPILER_FLAGS from Autotools

[swilmet]

See:
https://www.gnu.org/software/autoconf-archive/ax_compiler_flags.html#ax_compiler_flags

This is a macro used in GNOME for example (the *.m4 macro has been written by a GNOME developer).

Currently with Meson I need to copy/paste the following snippet of code from one project to another, and also when new flags are added upstream to AX_COMPILER_FLAGS, I need to update the Meson code in all my projects.

#####
# CFLAGS
# The same as the AX_COMPILER_FLAGS Autotools macro.

warning_cflags = [
    '-fno-strict-aliasing',
    '-Wall',
    '-Wextra',
    '-Wundef',
    '-Wnested-externs',
    '-Wwrite-strings',
    '-Wpointer-arith',
    '-Wmissing-declarations',
    '-Wmissing-prototypes',
    '-Wstrict-prototypes',
    '-Wredundant-decls',
    '-Wno-unused-parameter',
    '-Wno-missing-field-initializers',
    '-Wdeclaration-after-statement',
    '-Wformat=2',
    '-Wold-style-definition',
    '-Wcast-align',
    '-Wformat-nonliteral',
    '-Wformat-security',
    '-Wsign-compare',
    '-Wstrict-aliasing',
    '-Wshadow',
    '-Winline',
    '-Wpacked',
    '-Wmissing-format-attribute',
    '-Wmissing-noreturn',
    '-Winit-self',
    '-Wredundant-decls',
    '-Wmissing-include-dirs',
    '-Wunused-but-set-variable',
    '-Warray-bounds',
    '-Wimplicit-function-declaration',
    '-Wreturn-type',
    '-Wswitch-enum',
    '-Wswitch-default',
    '-Wduplicated-cond',
    '-Wduplicated-branches',
    '-Wlogical-op',
    '-Wrestrict',
    '-Wnull-dereference',
    '-Wjump-misses-init',
    '-Wdouble-promotion'
]

c_compiler = meson.get_compiler('c')
supported_warning_cflags = c_compiler.get_supported_arguments(warning_cflags)
add_global_arguments(supported_warning_cflags, language : 'c')
##### end CFLAGS

Note that this is not an exact copy of what AX_COMPILER_FLAGS does, it's just what I needed from it.

[nirbheek]

Note that this is GCC-specific, and the list of arguments is different for MSVC. It would be probably be useful to add a build option for this.

[tp-m]

Or a gnome module thing if these are standard compiler flags across many gnome modules?

[swilmet]

Initially the Autotools macro was part of gnome-common (GNOME_COMPILE_WARNINGS) and used by almost all GNOME modules I think. But now gnome-common is deprecated, the macros have been improved by Philip Withnall and included in a more upstream location, autoconf-archive. So I think AX_COMPILER_FLAGS is now more general than GNOME.

[ebassi]

While I was a huge proponent of standardised compiler flags in the past, I’ve come around to this and I find them just a way to impose misery on the people building projects, as well as a way for maintainers to stop thinking critically about their own project. It’s a dereliction of duty.

Not all projects have the same requirements when it comes to the subset of the language they use, and more importantly not all projects should defer to another project what it’s considered “correct” code. If you want to do that, build with -Wextra, and let the compiler maintainers be the arbiters of what’s good code.

If you want to add compiler warnings for your own development purposes (for instance because you have CI done on pull requests and CD on the whole stack) then you should be the one maintaining that list of warnings, and keep it up to date.

[mcatanzaro]

Anyway, we already have standardized compiler flags, based on the project warning_level, that chooses to add -Wall (default), -Wextra, -pedantic. Customizations beyond that should be done on a project-specific basis IMO.

The real problem is that warning_level is undocumented, so there's no way you could know about it unless you've looked at other meson build files, where it's been cargo-culted around.

[smcv]

If you want to do that, build with -Wextra

The problem with -Wall -Wextra is that a couple of the warnings that it enables are specifically not wanted by a lot of projects - namely -Wno-unused-parameter and -Wno-missing-field-initializers - and it's non-obvious which order the compiler command-line needs to be in to make sure those warnings never cause a build failure, particularly in conjunction with -Werror. https://cgit.freedesktop.org/telepathy/telepathy-glib/commit/m4/tp-compiler-warnings.m4?id=27a1090a2a8c19aa7e25e85f86a7e372439dd259 illustrates the problem.

AX_COMPILER_FLAGS grew into a list of recommended warnings to (not) enable, and that's the part I'm least attached to. The piece of knowledge I'm more concerned about having to cargo-cult between projects is the logic that says: if I want warnings X, Y and Z (optionally breaking the build when they happen), and I specifically don't want warnings U, V and W, what order does the command line need to be in to make that work?

(Having said that, I'm not sure whether AX_COMPILER_FLAGS does that flag ordering perfectly correctly either)

[3v1n0]

Also a warning_ldflags would be nice to have set.

[mcatanzaro]

Anyway, we _already_ have standardized compiler flags, based on the project warning_level, that chooses to add -Wall (default), -Wextra, -pedantic. Customizations beyond that should be done on a project-specific basis IMO.

The real problem is that warning_level is undocumented, so there's no way you could know about it unless you've looked at other meson build files, where it's been cargo-culted around.

I think this issue should be closed.

[pwnorbitals]

Anyway, we _already_ have standardized compiler flags, based on the project warning_level, that chooses to add -Wall (default), -Wextra, -pedantic. Customizations beyond that should be done on a project-specific basis IMO.
The real problem is that warning_level is undocumented, so there's no way you could know about it unless you've looked at other meson build files, where it's been cargo-culted around.

I think this issue should be closed.

I agree

[xclaesse]

I agree the set of warnings you want is really project specific. -Wall is an arbitrary set, AX_COMPILER_FLAGS is another, meson could add a 3rd but it would still be imposing a subjective vision to different projects. That being said, GNOME could be seen as an homogeneous project that wants to same rules across all its components, and in that case Meson has a gnome module that could serve that purpose. But I'm not even sure that all GNOME projects actually wants the same warnings, some parts of GNOME have widely different usage.

[dcbaker]

xorg has a similar thing, and I've been planning to add an xorg module that has all of the standard xorg warning flags in it, so I think it could make sense for gnome to have a gnome.warning_flags() (or whatever name).

[swilmet]

-Wall is an arbitrary set, AX_COMPILER_FLAGS is another

One problem that I see is that Meson is not extensible. If some users, even if it's just one user, wants a feature that is not present in Meson, the Meson project needs to be open to accept such features. The feature, whatever it is, can be put in a module, and that module could be maintained by its author.

A related problem that I see is the fact that once a feature is contributed upstream in Meson, the contributor can disappear and the Meson core maintainers have more and more code to maintain, hence the reluctance to accept all features.

[xclaesse]

@swilmet We are trying to transfer responsibility of maintaining meson modules to different people/teams. I think people from GNOME community should decide and maintain what we add in the meson gnome module as long as it's not affecting the core of meson, or doing stuff against some basic design principles of meson. So if someone from GNOME community writes a PR to add API to get warning flags, I would be happy with that.