I am pleased to announce a new GNUstep project containing a set of scripts to
build GNUstep for Windows with Clang and libobjc2 using the Visual Studio
toolchain and MSVC ABI (i.e. without MinGW):
https://github.com/gnustep/tools-windows-msvc
The scripts currently build GNUstep Base with all dependencies, plus also
libdispatch. Invoking build.bat from an x86 or x64 Visual Studio developer
command prompt will build all libraries for that architecture for both debug
and release CRT libraries. Each library is either build directly in the Windows
shell (libobjc2, libiconv, libxml2, libxslt), or an MSYS2 Bash shell is spawned
for libraries requiring such an environment (libffi, GNUstep Make/Base).
I only found usable pre-built binaries for Pthread-win32 and ICU (and no good
way to integrate NuGet packages), so all the others are built from source.
Since building for MSVC is far from standard for projects coming from Unix (but
fortunately always supported in some way it seems), each of them requires their
very own special setup, and required a lot of massaging to get everything
working.
The resulting set of DLLs should be usable to integrate Objective-C code in
basically any Windows app that is not using MinGW, using either clang or
clang-cl to build ObjC code. The Readme contains some info on the required
compiler and linker flags. Hopefully down the line we can also get other
GNUstep libraries on board as to offer a more complete GNUstep package for
Windows MSVC.
(I also took a brief stab at trying to build Objective-C code in Visual Studio,
but unfortunately it adds a /TP flag forcing clang-cl to treat the input as C++
(just like CMake). I’m guessing there are ways around this as WinObjC was able
to integrate ObjC files in VS, which we can hopefully figure out some time.)
While many tests in Base are still failing for various reasons, I plan on
spending more time on this in the coming months and will also try to add MSVC
to the Travis CI setup so we can ensure the configuration stays supported. I
already set up CI via GitHub Actions for the scripts themselves (not running
any tests atm.). (And btw. GitHub Actions runners seem *much* faster than
Travis CI.)
Thank you all and especially David for helping me get this working, and bearing
with me through all my messages to the mailing list on this topic over the last
year! I’m looking forward to see what comes out of this effort.
Frederik