Support building for Windows with clang-cl

[fanc999-1]

Hi,

This attempts to add build support for Windows using clang-cl (the flavor of clang that attempts to mimick Visual Studio and uses the Microsoft SDKs, meaning _MSC_VER will also be defined), so that the build libraries and headers can also be better consumed by items built using Visual Studio. This is done to restore support to build libadwaita against the Microsoft tools/SDK.

This mainly consists of:

• Making the code compile with the Windows SDK by only including headers when they are really available.
• Using compiler directives to export symbols from shared builds via defining macros. Also, for the private symbols, define macros suitable for clang-cl for visibility. clang-cl (and Visual Studio) build DLLs with hidden visibility by default.
• Improve dep search using CMake names where needed also, as CMake build files for Visual Studio builds often do not produce pkg-config files for us. Also avoid hard-coding paths to find the libstemmer/snowball headers. Also do not enable systemd on Windows, since it is (and is unlikely ever) not available for Windows at all

With blessings, thank you!

[ximion]

Using compiler directives to export symbols from shared builds via defining macros.

Can this be done differently? I really don't like this, and it adds a ton of unnecessary noise to the code (it also doesn't look like other projects like GLib need this?).

The other changes look okay from a quick glance, thank you a lot for this work! Having CI for this will be very helpful! :-)

[ximion]

To elaborate on the exported symbols: AppStream exports everything on Linux/FreeBSD/MacOS that is not wrapped by AS_BEGIN_PRIVATE_DECLS/AS_END_PRIVATE_DECLS which simply switches the default symbol visibility to "hidden". Stuff in *-private.h headers is generally not exported. This setting can be overridden for individual symbols via AS_INTERNAL_VISIBLE. Those are exported, but are not part of the public API so must not be used outside of AppStream (and will not be available in public headers).

So all that would be needed is make clang export everything by default and adjust the macros to negate the export option for subsequent declarations with whatever commands Microsoft has set for that. That must be possible somehow, I'd imagine.

[fanc999-1]

Using compiler directives to export symbols from shared builds via defining macros.

Can this be done differently? I really don't like this, and it adds a ton of unnecessary noise to the code (it also doesn't look like other projects like GLib need this?).

The other changes look okay from a quick glance, thank you a lot for this work! Having CI for this will be very helpful! :-)

I'll try to see whether there are any better ways for this--GLib/Pango/GTK do have something like this though, however, via the GLIB_AVAILABLE* macros that decorate symbols, in GLib for instance, and on Visual Studio and clang-cl they will be defined as __decspec(dllexport) during the build.

---

It does seem the other way is to try to generate a .def file using dumpbin /exports dumpbin /symbols, but the price is likely that those in the visibility hidden section gets exported as well, so this is what I have here, along with an intermediate static lib that is built so that we can use call dumpbin easier.

---

Thanks for the suggestions though.

[ximion]

It's a bit ugly, but I guess we need to accept that :-) Why is the CI failing though?