<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 7:44 PM, Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tue, Feb 16, 2016 at 3:45 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> That's a bug in the CMake code<br>
> (which I hope will be history in a few months).<br>
<br>
</span>Are you indicating using an alternative build system?<br></blockquote><div><br></div><div>yes. In <a href="http://www.squeakvm.org/svn/squeak/branches/Cog">http://www.squeakvm.org/svn/squeak/branches/Cog</a> 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</div><div><br></div><div><div> build.macos32x86/pharo.cog.spur/Makefile:</div><div><font face="monospace, monospace">##############################################################################</font></div><div><font face="monospace, monospace"># Makefile for Mac OS X Cog Spur Pharo Cocoa VM using clang and gnu make 3.81</font></div><div><font face="monospace, monospace"># Do make init to allow make -n to function.</font></div><div><font face="monospace, monospace">#</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">VMSRCDIR:= ../../spursrc/vm</font></div><div><font face="monospace, monospace">VM:=Pharo</font></div><div><font face="monospace, monospace">CFLAGS:=-DPharoVM=1</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"># Now include the Makefile proper, which is common to all Mac OS builds.</font></div><div><font face="monospace, monospace">#</font></div><div><font face="monospace, monospace">include ../common/Makefile.app</font></div></div><div><br></div><div><div>build.macos32x86/squeak.stack.spur/Makefile </div><div><font face="monospace, monospace">##############################################################################</font></div><div><font face="monospace, monospace"># Makefile for Mac OS X Stack Spur Squeak Cocoa VM using clang and gnu make 3.81</font></div><div><font face="monospace, monospace"># Do make init to allow make -n to function.</font></div><div><font face="monospace, monospace">#</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">VMSRCDIR:= ../../spurstacksrc/vm</font></div><div><font face="monospace, monospace">SOURCEFILE:=SqueakV50.sources</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"># Now include the Makefile proper, which is common to all Mac OS builds.</font></div><div><font face="monospace, monospace">#</font></div><div><font face="monospace, monospace">include ../common/Makefile.app</font></div></div><div><br></div><div><br></div><div>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. <a href="http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common">http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common</a>) 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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">btw, last week I came across Ninja [1], a static build system designed<br>
to be used higher level generators, which for us could be Smalltalk.<br>
[1] <a href="http://jpospisil.com/2014/03/16/replacing-make-with-ninja.html" rel="noreferrer" target="_blank">http://jpospisil.com/2014/03/16/replacing-make-with-ninja.html</a></blockquote><div><br></div><div>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 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common/Makefile.rules">http://www.squeakvm.org/svn/squeak/branches/Cog/build.macos32x86/common/Makefile.rules</a>. 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.</div><div><br></div><div><div><font face="monospace, monospace">#define USE_X11 1</font></div><div><font face="monospace, monospace">#define USE_X11_GLX 1</font></div><div><font face="monospace, monospace">/* #undef USE_QUARTZ */</font></div><div><font face="monospace, monospace">/* #undef USE_QUARTZ_CGL */</font></div><div><font face="monospace, monospace">/* #undef USE_RFB */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">/* libraries */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">/* #undef HAVE_LIBX11 */</font></div><div><font face="monospace, monospace">#define HAVE_LIBXEXT 1</font></div><div><font face="monospace, monospace">#define HAVE_LIBDL 1</font></div><div><font face="monospace, monospace">/* #undef HAVE_DYLD */</font></div><div><font face="monospace, monospace">/* #undef HAVE_LIBFFI */</font></div><div><font face="monospace, monospace">/* #undef HAVE_ICONV */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">/* #undef USE_AUDIO_NONE */</font></div><div><font face="monospace, monospace">/* #undef USE_AUDIO_SUN */</font></div><div><font face="monospace, monospace">/* #undef USE_AUDIO_NAS */</font></div><div><font face="monospace, monospace">/* #undef USE_AUDIO_OSS */</font></div><div><font face="monospace, monospace">/* #undef USE_AUDIO_MACOSX */</font></div><div><font face="monospace, monospace">/* #undef OSS_DEVICE */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">/* header files */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">#define HAVE_UNISTD_H 1</font></div><div><font face="monospace, monospace">/* #undef NEED_GETHOSTNAME_P */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">#define HAVE_DIRENT_H 1</font></div><div><font face="monospace, monospace">/* #undef HAVE_SYS_NDIR_H */</font></div><div><font face="monospace, monospace">/* #undef HAVE_SYS_DIR_H */</font></div><div><font face="monospace, monospace">/* #undef HAVE_NDIR_H */</font></div><div><font face="monospace, monospace">#define HAVE_DLFCN_H 1</font></div><div><font face="monospace, monospace">#define HAVE_ICONV_H 1</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">#define HAVE_SYS_TIME_H 1</font></div><div><font face="monospace, monospace">#define TIME_WITH_SYS_TIME 1</font></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">cheers -ben<br></blockquote></div><div><br></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>