gnome.generate_gir(): add 'fatal_warnings' argument

[gdesmott]

When building with werror=enabled gnome.generate_gir() should pass --warn-error to the gir generator so its own warnings are fatal as well.

[tp-m]

I'm very wary of this, not sure this is a good idea at all to link this to the global meson --werror option.

It's pretty difficult in a complex code base to make g-ir-scanner warning-free even more so whilst supporting a range of gobject-introspection versions.

Maybe we should look into adding either module options, or a new kwarg (which projects could then link to a custom option)?

[gdesmott]

We can already do it manually by passing --warn-error to the extra_args kwarg. I was considering how to do that in GStreamer when I figured it may be useful to have it directly into meson.

Maybe this could be gated with a specific warning-level?

[tp-m]

Maybe this could be gated with a specific warning-level?

Right, but my concern was basically the ability to do the normal -Wall -Werror for C/C++ compilers.

Maybe one could have something like --werror-domains=c,cpp,introspection?

Or maybe I'm just worried unnecessarily, but I just don't feel g-i has the same kind of maturity level as a proper compiler and we'll need to be able to work around wrong warnings or it otherwise getting confused (e.g. it's pure luck that your trick in gst-plugins-base worked and g-i didn't pick up on the types being different, isn't it? What do we do if it starts warning about that in the next version?)

[gdesmott]

Can't users just workaround warnings by annotating the symbol with (skip)? If most errors lead to the gir to be generated with introspectable=0 it doesn't change anything for gir users and will force developers to acknowledge those problems.

[tp-m]

Maybe, I don't know if all/most warnings lead to introspectable=0. If yes then that seems reasonable to me.

[gdesmott]

Looks like silenting those warnings is actually not that easy. So I agree with you, using werror is not a good idea in the current gir state.

What about adding a fatal_warning kwars to gnome.generate_gir() which would accept either a boolean or a feature option? So projects could just do something like this:

gnome.generate_gir(...
  fatal_warning : get_option('gir-fatal-warnings')
)

[tp-m]

What about adding a fatal_warning kwars to gnome.generate_gir() which would accept either a boolean or a feature option? So projects could just do something like this:

I like that.

[tp-m]

adding a fatal_warning kwarg

Maybe plural though - fatal_warnings? That matches use elsewhere I think (e.g. G_DEBUG=fatal_warnings)

[xclaesse]

What about adding a fatal_warning kwars to gnome.generate_gir() which would accept either a boolean or a feature option? So projects could just do something like this:

Why would it be a feature option? "auto" would make no sense here... If it's a feature option in your project for whatever reason, you can just pass get_option('gir-fatal-warnings').enabled(), or not get_option('gir-fatal-warnings').disabled(), depending on the meaning you want to give to auto.

Maybe plural though - fatal_warnings? That matches use elsewhere I think (e.g. G_DEBUG=fatal_warnings)

+1, we have meson setup --fatal-meson-warnings already, which itself is inspired from glib.

[gdesmott]

Why would it be a feature option? "auto" would make no sense here... If it's a feature option in your project for whatever reason, you can just pass get_option('gir-fatal-warnings').enabled(), or not get_option('gir-fatal-warnings').disabled(), depending on the meaning you want to give to auto.

Can we do fatal_warning : get_option('gir-fatal-warnings') with a boolean option? Then I think it's fine then.
As long as we can enable/disable it easily I'm happy. :)

[xclaesse]

Yes that works

[tp-m]

Why would it be a feature option? "auto" would make no sense here.

auto would simply mean "I don't care one way or another and will leave it up to circumstances", it provides space for doing different things by default later.

Not very important in this case though.