search

gnustep / tools-windows-msvc

Objective-C on Windows using Clang and GNUstep.
MIT License
44 stars 10 forks source link

Add support for headless libs-back backend #31

Closed qmfrederik closed 1 year ago

qmfrederik commented 1 year ago

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 commented 1 year ago

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

qmfrederik commented 1 year ago

@triplef Should be good now!

gcasa commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.