New Build Executables, New Build Strategy

[hostilefork]

Encouraged by my increased familiarity with GitHub Actions by doing the TCC Bootstrap, I took it further and have done our first Windows-Server Based CI Builds !

This contrasts to how we did Windows builds on Travis, which was with cross-compilation using MinGW. We built Windows executables on Linux. This wasn't so bad for just the basic core of the interpreter. But once you stretched outside of that to wanting to link to strange libraries (ZeroMQ, FFI) you would run into problems because those libraries expected you to be running Windows if building for Windows.

To build on Windows Server without a GUI, I had to brush up the command-line-based building with Microsoft NMAKE...which is working well enough that I just deleted the support for Visual Studio altogether.

And good riddance! VSCode handles all the necessary C/C++ browsing features without needing a giant XML project file. You can jump to declaration, get autocompletion, and debugging...all without needing some gargantuan XML File.

This is a good step back toward the direction we want to go:

@hostilefork

To most observers (including myself), Rebmake is way too big. It makes sense if you think the goal is to generate CMake files or Visual Studio files. But what you wind up with in this line of thinking is kind the direct opposite of Rebol's goals: instead of making a thing that is significantly less complicated than those systems, you have something that inherits all their complexity and then layers on more.

The TCC Bootstrap is helping put a sharper focus on what we actually want out of Rebmake: to build without needing any CMake or GNU Make or otherwise. Now to just make it good...