[Vm-dev] Why the hell directives for compiling with clang were not taken into account

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 3 15:24:55 UTC 2018


Hi Subbu

> On Apr 3, 2018, at 7:34 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
>> On Tuesday 03 April 2018 06:00 PM, Eliot Miranda wrote:
>> I'm feeling beaten down.  Perhaps you could read the code?  Compare what's in platforms/unix/config with what's in build.macos32x86/common build.macos64x64/common build.win32x86/common
>> build.win64x64/common
>> And then think about the "necessary configure step".  To what extent does it make sense to run a configure step on a build machine that makes a binary that is downloaded and used on machines that may differ markedly from that build machine?
> 
> The configure script in Autoconf accumulates lots of platform-fu (see
> configure:5668) for all the UNIX/Linux variants and quirks.

Right.

> 
> Mac or Win ports have to deal only with a handful of variants, so
> hand-crafted Makefiles are sufficient. But Unix/GNU/Linux ports are so
> numerous and diverse that Ian Piumarta (?) brought in autoconf to ease
> porting Squeak to all these variants.

I see things a little differently.  I don't want to speak for Ian, but I expect that the reason Ian went the way he did was more to do with the fact that to run Squeak one had to build a vm oneself. Being a Unix expert Ian could support a build of (at first just) an X11 vm across a wide range of Unix variants at a time (the early 90's) when many manufactures were oroducing Unix workstations which were widely used, especially in academia.  That predated a lot of culture we now take god granted, the downloading of prepackaged releases, automated build and test environments, and a much reduced more consumer-oriented laptop market.

> If we don't intend to support all the 100+ variants of GNU/UNIX/Linux out there but only a handful, then manual makefiles are sufficient.

It's not that we do of do not intend, it's that we simply cannot afford to and it is not relevant to our current needs.  We instead need to support a much smaller number of operating systems well, namely Linux and maybe FreeBSD, although I don't see much energy there.  We could keep the old build system for those that want to build their own vm on something exotic (although I'd still argue that they would do as well working with conventional makefiles).  But it is no longer fit for purpose in the continuous integration context we now inhabit.

> 
> GNU Make is available on GNU/Linux/Mac/Win so we could create a single top level Makefile for all three platform builds and let the configure
> handle other ports.

Having modified Andreas' makefiles for windows, and having written the makefiles for the Mac build I can say that a common top level makefiles is not a good idea.  It would be even more of a mess of ifdefs.  But certain not following the way nudes and Mac OS schemes is sensible.  The important thing is to get rid of the extremely hard to modify, slow autoconf based system used for Linux builds.

> CMake is another possibility but it requires meta makefiles to be created from scratch :-(.

In a vm text where build slaves build binaries god more general consumption the specificity of CMake and autoconfig is of marginal utility.  The Windows and Mac OS sources still have config.h's; they simply aren't generated on every build.  The information in them doesn't change in practice, except when a major change, such as the addition of s 64-bit build, occurs, and at that point a lot more work than merely updating config.h is needed (although IIRC  the mac's config.h didn't change when adding 64-bit Spur).

The main utility in CMake and autoconf is /not/ capturing platform fu, but in capturing what ancillary packages have been installed to know what additional plugins to build; for example the 3D plugins are only built if OpenGL is installed.  But in our CI infrastructure we make damn sure OpenGL is installed on the build machines so we. An provide VMs comprising a full set of plugins, some of which may not work on the user's machine because they haven't installed the libraries.

Let's have a build system that suits where we are now, where the vm is a utility we want to build reliably and download, not something we get a frisson form building ourselves.  Let's leave that yo those that work on the vm and let the rest of us get timely CI vm builds we can download at our leisure.

> Regards .. Subbu

Cheers!
Eliot


More information about the Vm-dev mailing list