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

On Tue, Feb 16, 2016 at 3:45 AM, Eliot Miranda <eliot.miranda@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/Make.... 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

That should be fixed in my lasts commits... Which version is the ppa using? (I'm out 'till Thursday, sorry I cannot provide more support right now :( ) Esteban

On 16 feb 2016, at 9:41 a.m., Damien Cassou <damien.cassou@inria.fr> wrote:

Hi Eliot,

Eliot Miranda <eliot.miranda@gmail.com> writes:

...

On Mon, Feb 15, 2016 at 10:37 AM, Markus Fritsche <mfritsche@reauktion.de> wrote:

...

I was just going to update the ubuntu ppa an wanted to supply a spur vm image. The compilation stopped however:

-- Configuring done CMake Error at IA32FFIPlugin/CMakeLists.txt:11 (add_library): Cannot find source file:

/home/mfritsche/src/pharo-vm-spur-2016.02.13/src/plugins/IA32FFIPlugin/IA32FFIPlugin.c

That's a bug in the CMake code (which I hope will be history in a few months). tt should be looking *only* for

src/plugins/SqueakFFIPlugin/SqueakFFIPlugin.c

which should include

src/plugins/SqueakFFIPlugin/IA32FFIPlugin.c

do you know what we have to change and where exactly? I also face the same problem.

Thanks

-- Damien Cassou http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill