Bump compiler requirement and coding style to C99

changed milestone to %1.19.1

Yes please

mentioned in merge request gst-plugins-bad!1907 (closed)

mentioned in commit gdesmott/gst-build@743f2a00

mentioned in commit gdesmott/gstreamer@764f1b02

I was curious wondering how hard this change would be. Looks like all the jobs are passing except clang build which isn't happy with the #pragma once used in gst-editing-services.

except clang build which isn't happy with the #pragma once used in gst-editing-services.

Is this really because of the #pragma once and not some typedef shenanigans as the error message seems to imply?

Meson uses #pragma once for config.h and it hasn't been a problem so far, so I don't know if that's the issue?

Is this really because of the #pragma once and not some typedef shenanigans as the error message seems to imply?

You're right, actually I think that's because ges-types.h is defining all the type structs which are re-defined by G_DECLARE_FINAL_TYPE.

The other question I have is whether we should really use c_std=gnu99, if it doesn't force the compiler into an ancient mode (i.e. disable newer features which might optionally be used otherwise), because the compiler will default to something newer otherwise, no? (gnu17 for gcc I believe)

Don't know, I just used gnu99 as that's what's used by GLib.

I think we can just document/say that "it's ok if you do these things now" and document that compiler needs to support C99 and leave it at that?

Note there is/was related issue in Meson itself with c_std=gnu99. We require c99 but can use GNU extensions if available. There is no syntax in meson to tell "I want gnu99 if possible, but I'm fine with c99".

The other question I have is whether we should really use c_std=gnu99, if it doesn't force the compiler into an ancient mode (i.e. disable newer features which might optionally be used otherwise), because the compiler will default to something newer otherwise, no? (gnu17 for gcc I believe)

But we want to error out when using new features from gnu17, even if the compiler is capable, no?

But we want to error out when using new features from gnu17, even if the compiler is capable, no?

There are some things like e.g. atomics and such where those are hidden behind a feature check which we wouldn't want to disable.

As I see it, this is issue is primarily about community consensus, we don't need to enforce it via build options (just like we did not specify C89 before). Doing this at the gst-build level might also have undesireable effects on subprojects that are out of our control.