mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2025-02-09 12:25:48 +01:00
627dc1415c
This reverts commit 252bbcd2078aadc67a49bacd5b2cd4fd348a8dd7. After further discussion in !3511, we’ve decided that there are risks associated with this change, and it’s not the best way of addressing the original problem. The original motivation for the change turned out to be that `-mms-bitfields` was not handled by `windres`, which was receiving it from `pkg-config --cflags glib-2.0` in some projects. However, if `windres` is claiming to accept CFLAGS then it should accept (and ignore) `-mms-bitfields`, since the `-m` family of options are defined in `man gcc`, just like `-I`, `-D`, etc. There is some question that there might still be third party projects which are built with an old enough compiler that `-mms-bitfields` is not the compiler default. For that reason, we should either still continue to specify `-mms-bitfields` in the `.pc` file, or add a test to assert that third party projects are always compiled with `-mms-bitfields` set. But adding a new test for all third-party compilations is risky (if we get it wrong, things will break; and it’s a test which may behave differently on different platforms), so it seems safer to just keep `-mms-bitfields` in `.pc` for now. Once all compilers which we require specify `-mms-bitfields` by default, we can finally drop this flag (without adding a test for third-party compilations). See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3511