This way, the generated GResource code won't choke if no prototypes are found
when being built by clang-cl, which also goes the _MSC_VER >= 1500 route.
Fixes clang-cl build of generated GResources code when building the appstream
git checkout, which supported Windows recently, as the build there demands
'-Werror,-Wmissing-prototypes'.
Part-of: <https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3589>
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files glib/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
We only want to include gslist.h here if it was not already included via
including glib.h, as:
* gslist.h should normally be included via glib.h if used outside of
GLib itself.
* This broke Visual Studio builds that use GResources (via
glib-compile-resources.exe) as that would cause the generated code to
include gslist.h directly, which is therefore disallowed.
Symbols on x86 are prefixed with an underscore
but symbols on x64/ARM/ARM64 are not.
Relevant information concerning the prefixes for the architectures
can be found in the vcpkg project [1,2], where arm and arm64 builds
are part of the CI.
Specifically, _WIN64 is defined on Windows ARM64, so this issue is
only visible when building on ARM32.
[1] 08e74979df/ports/glib/fix-arm-builds.patch
[2] https://github.com/microsoft/vcpkg/pull/6116
Whole program optimization is enabled by default in visual studio
release builds, and this causes constructors (for e.g. resources) to be
optimized away as they are not referenced from elsewhere.
This works around this by some pragma magic.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
With this we're not longer exporting the constructor headers, which means
we're not tying ourselves to a macro that might need special tweaking on
a compiler-by-compiler basis.
