[Vm-dev] Re: [Pharo-dev] Compiling the unix vm / spur

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 16 04:18:06 UTC 2016


On Mon, Feb 15, 2016 at 7:44 PM, Ben Coman <btc at openinworld.com> wrote:

> On Tue, Feb 16, 2016 at 3:45 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> > That's a bug in the CMake code
> > (which I hope will be history in a few months).
>
> Are you indicating using an alternative build system?
>

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

 build.macos32x86/pharo.cog.spur/Makefile:
##############################################################################
# Makefile for Mac OS X Cog Spur Pharo Cocoa VM using clang and gnu make
3.81
# Do make init to allow make -n to function.
#

VMSRCDIR:= ../../spursrc/vm
VM:=Pharo
CFLAGS:=-DPharoVM=1

# Now include the Makefile proper, which is common to all Mac OS builds.
#
include ../common/Makefile.app

build.macos32x86/squeak.stack.spur/Makefile
##############################################################################
# Makefile for Mac OS X Stack Spur Squeak Cocoa VM using clang and gnu make
3.81
# Do make init to allow make -n to function.
#

VMSRCDIR:= ../../spurstacksrc/vm
SOURCEFILE:=SqueakV50.sources

# Now include the Makefile proper, which is common to all Mac OS builds.
#
include ../common/Makefile.app


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.

btw, last week I came across Ninja [1], a static build system designed
> to be used higher level generators, which for us could be Smalltalk.
> [1] http://jpospisil.com/2014/03/16/replacing-make-with-ninja.html


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.

#define USE_X11 1
#define USE_X11_GLX 1
/* #undef   USE_QUARTZ */
/* #undef   USE_QUARTZ_CGL */
/* #undef   USE_RFB */

/* libraries */

/* #undef   HAVE_LIBX11 */
#define HAVE_LIBXEXT 1
#define HAVE_LIBDL 1
/* #undef   HAVE_DYLD */
/* #undef   HAVE_LIBFFI */
/* #undef   HAVE_ICONV */

/* #undef   USE_AUDIO_NONE */
/* #undef   USE_AUDIO_SUN */
/* #undef   USE_AUDIO_NAS */
/* #undef   USE_AUDIO_OSS */
/* #undef   USE_AUDIO_MACOSX */
/* #undef   OSS_DEVICE */

/* header files */

#define HAVE_UNISTD_H 1
/* #undef   NEED_GETHOSTNAME_P */

#define HAVE_DIRENT_H 1
/* #undef   HAVE_SYS_NDIR_H */
/* #undef   HAVE_SYS_DIR_H */
/* #undef   HAVE_NDIR_H */
#define HAVE_DLFCN_H 1
#define HAVE_ICONV_H 1

#define HAVE_SYS_TIME_H 1
#define TIME_WITH_SYS_TIME 1

cheers -ben
>

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160215/6499cccb/attachment.htm


More information about the Vm-dev mailing list