Add support for headless libs-back backend

[qmfrederik]

We're in a much better place to start building libs-back for the msvc toolchain now that gnustep/libs-gui#177 and gnustep/libs-gui#179 have been merged.

This PR starts building libs-back for msvc. It doesn't build the full Win32 backend, but relies on a headless backend instead, which is hopefully coming via gnustep/libs-back#42. This PR is probably blocked until that lands; but opening it for visibility.

Supporting the full Win32 backend would require additional fixes and could come in a follow-up PR.

[triplef]

Nit: do you mind adjusting the indentation here to match the rest (I think 4 spaces)?

[qmfrederik]

Ah, missed that one. Thanks for spotting it! Should be fixed now.

[triplef]

Thanks @qmfrederik! Looks fine to me. Could you just please fix that indentation?

[qmfrederik]

@triplef Should be good now!

[gcasa]

@triplef @qmfrederik For keysight purposes the backend should be headless, but for generic GS purposes, the default backend still needs to be a graphical one.

[qmfrederik]

@gcasa Yup, I agree. As I wrote in the PR description:

Supporting the full Win32 backend would require additional fixes and could come in a follow-up PR.

[triplef]

Could you explain to me how the headless backend can be used and why Keysight doesn’t need a full backend? (Unfortunately I’m a total noob when it comes to libs-gui and everything related...)

[qmfrederik]

The headless backend allows you to use gui components without having them actually render anything to your screen. In our case, we have an application which runs both in command line as well as full GUI mode. Even when running in command line mode, some code from libs-gui is invoked. The headless backend allows us to run those applications.

There may be other use cases, too. For example, I think this would allow you to run code which relies on libs-gui in e.g. a container environment, for, say, unit testing purposes as part of your CI pipeline.

I agree we should try to get the full Win32 backend building with msvc. I think both @gcasa and myself have branches on which this is working, but I do think the patches require cleanup (see e.g. https://github.com/qmfrederik/tools-windows-msvc/blob/features/libs-back/patches/gnustep-back-win32-fixes.patch) and this seemed like a quick way to enable some functionality.

Hope this helps, let me know if there are further questions!

[triplef]

Thanks for the explanation!

Yes would be great to see full backing support down the line (I believe that would also give this toolchain feature parity with the old MinGW one), but makes total sense to take this step first.