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

Stuart Cassoff aa72 at bell.net
Fri Apr 6 08:30:48 UTC 2018


> > 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.

> >> namely Linux and maybe FreeBSD, although I don't see much energy
> >> there.

And yet Alan Kay can boast that Squeak runs with binary compatibility on 20+ "systems".

I wouldn't normally say anything without work to back it up but I found this somewhat disheartening although I do realize the reality of scarce resources.

Here are some scattered thoughts and a question:

I've been successfully building all VMs on OpenBSD for like a year now.
My work is online but I haven't had time for it lately.

I can't say I'm enjoying seeing /bin/sh -> /bin/bash or any other gnuisms either existing or creeping in.

It shouldn't be hard for the shell scripts to be written in portable shell, considering their size and simplicity.
I've actually done most of this work and will push online rsn.

I suspect the Makefiles need gnu make but I'm optimistic something could be done there.

Why curl *and* wget?

If you want to build on unix you'll want to use autoconf (2.69), especially for 3rd party software.*
I worked on a Squeak port when Squeak was dallying with CMake and it wasn't fun. Please no CMake.

Lots of Makefiles and lots of ifdefs is surely the path to madness.


Stu

*Autoconf for 3rd party isn't even enough sometimes. Did you know some systems can have three libuuids installed at the same time?

> ---------- Original Message ----------
> From: Eliot Miranda <eliot.miranda at gmail.com>
> Date: April 3, 2018 at 4:31 PM
> 
> 
>  Hi Subbu,
> 
> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
> >
> > On Tuesday 03 April 2018 08:54 PM, Eliot Miranda wrote:
> >
> > 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.
> >>
> >
> > Valid point. The CI pipeline requires a different approach.
> >
> >
> >>> 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.
> >>
> >
> > A top level Makefile does not exclude platform-specific Makefiles, nor
> > should it attempt a cross-platform build by itself.
> >
> > The purpose of top level Makefile is general help, handle version tags,
> > possible products and variants etc. It should delegate the actual build to
> > platform-specific make. Similar to how we use OSProcess as a facade over
> > OSUnixProcess etc.
> >
> 
> Ah, thanks.  That makes sense.  Cool.
> 
> 
> > In fact, I am making one for my own use. Once it stabilizes, I will offer
> > a PR.
> >
> 
> Looking forward to it; thanks.
> 
> 
> >
> > The downsides to spreading Makefiles into build dirs is explosion of
> > directories under version control and duplication of code. It also means
> > that I cannot mount build on tmpfs/ramfs. Keeping Makefile templates under
> > platform/win32/.. and copying them to build/ as needed will simplify
> > version control and avoid duplicate code.
> >
> > Regards .. Subbu
> >
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot


More information about the Vm-dev mailing list