yes.�� In http://www.squeakvm.org/svn/squeak/branches/Cog I have just replaced the Xcode.xcodeproj/project.pbxproj "build system", which offers no procedural abstraction at all, with a small set of Gnu Makefiles.�� The result is that each of the various VMs: (newspeak | squeak | pharo) x (sista | cog | stack) x (spur x v3) has a small Makefile such as

instead of over 700k of useless Xcode junk per build.�� In comparison each of the new build directories takes less than 2k of text (16k bytes on disc in 4 files) and the common makefiles (see e.g. http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common) takes less than 24k of text (44k bytes on disc in 8 files).�� The new build system seems no slower, and it also signs the .app bundle. ��his is, IMO, a huge improvement over both Xcode and CMake.�� The makefiles are reasonably easy to modify.�� They're based on Andreas' makefiles for Win32.�� I've been able to simplify both and am finally getting some familiarity with gnu Make's set of functions.�� It's very satisfying to replace of the order of 6 Mb of make junk that requires an entire IDE to edit with less than 300k of stuff.�� It also means I have more or less the same build system on win32 and Mac OS X.

I think I may replace the Unix autoconf scheme with something similar.�� The only thing that's lacking in my scheme is a CMake or autoconf step to determine the platform's capabilities (to generate a config.h).�� If I do this right I think autoconf/CMake can be run once to initialize the build system, rather than once for every build.�� The intuition is that the platform doesn't change and the autoconf/CMake probe of the underlying platform can be done once and shared between all the builds.�� Then it needs to be redone on major OS upgrades, etc.�� But it /doesn't/ need to be done on every build.�� And gnu Make makes it easy to call-out to a common makefile that will run the autoconf/CMake step as required by the first build. ��$(realpath ...) is one's friend.

i don't mean to sound negative or arrogant but Ninja doesn't offer enough syntactic abstraction to be worth it.�� For example the rules given on that page are not much simpler than the rules in ��http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common/Makefile.rules.�� So IMO the right approach is a per-OS set of gnu Makefiles, all of which share more or less the same architecture, plus an autoconf/CMake step to generate the config.h file that includes all the relevant information about the underlying platform.�� Here's the kidn of information I mean.�� This is a subset of the generated config.h file on e.g. linux32x86.�� Right now generating this for every build takes a substantial fraction of the overall build time, not an issue for a slave, but a real issue for someone doing their own VM builds, and it's unnecessary replcation.