When R3-Alpha was open-sourced, the make directory contained one GNU makefile, and Carl gave these instructions:
About the Makefile:
You might notice that the makefile is a bit old-fashioned. That’s because I still support REBOL on some very old systems that don’t offer newer makefile features. So, please keep that in mind and stick with this simple format.
Also, the makefile is built by REBOL. Typing “make make” will rebuild it, and you can also select a different platform target the same way by providing the REBOL platform identifiers (the last two parts of the version string).
Parts of REBOL are built by REBOL. So, to build it, you’ll need to download a running binary into the local make directory. Call it r3-make.
The build happens in the make directory. It will create an obj sub-dir for storing the object files. I prefer this over mixing the source and object files into the same directory.
The biggest step is to do the “make prep” which will use REBOL to configure and build a number of important C header files.
If you are building for a new platform that has no existing REBOL, you can use “make prep” to build all the files you need on an existing platform and copy them to the new platform.
After the prep, just run “make” and the rest of the system will build.
One might ask: if the makefile is built by Rebol, why would it be committed in the repository? What platform is this makefile for? What happens if you just say
The answer is that the makefile was generated for 32-bit Linux (0.4.4), so it was produced by running the command
r3-make %../src/tools/make-make.r OS_ID=0.4.4. However, it contains a trick: it has a target itself called “make” such that once generated, running
make make OS_ID=0.X.Y will overwrite the makefile itself with an updated version for that OS.
We found this annoying, because the committed
makefile would appear dirty in version control if you are using another system. And also, one could streamline this process a bit for the average person if instead of them having to go look at the %systems.r table and find their platform, if the
r3-make could inspect its own
system/version and assume you wanted to build that same OS_ID.
And so %make/makefile.boot was born. It was a committed file which saved you all the trouble of typing
./r3-make ../src/tools/make-make.r followed by
make r3. Instead you could now type
make -f makefile.boot.
If it sounds stupid, it kind of is. But it wasn’t rocket science to write, and you could also think of it as a kind of an interactive README file…if you didn’t have something you needed, it could tell you. And given that the build process was already dependent on you having GNU make, it could also catch you on that “meta-step” of needing make in the first place.
But we live in a different world now. You no longer need GNU make to build Ren-C. You can still target it, but you can also generate files for Microsoft’s NMAKE, or a Visual Studio project file. And you can even forego the idea of a makefile altogether–instead having the Rebol executable drive the build process using
CALL on the C compiler directly. So it’s time to scrap %makefile.boot and let a Rebol script be the entry point to the process.
I’m going to be talking about platforms, building, extensions in some more technical posts. But this is more a philosophy post, or user-experience question. Maybe any points people want to raise about building a system where it’s been done right?
One thing we definitely should make easier is bootstrapping to new platforms. The generated products of a Rebol “prep” process need to be in one central place to be grabbed and moved over. Bootstrapping in this way should be part of the test process, e.g. one of the Travis instances that does a Win32 build on Linux could do the Win32 prep using the native Linux executable. And then make sure it can just move the one folder with prep products into a completely fresh git install and still build with the cross-compiler…