[Vm-dev] Why the hell directives for compiling with clang were not taken into account
Stuart Cassoff
aa72 at bell.net
Fri Apr 6 17:36:34 UTC 2018
> ---------- Original Message ----------
> From: Eliot Miranda <eliot.miranda at gmail.com>
> Date: April 6, 2018 at 9:55 AM
>
>
>
> Hi Stuart,
>
> > On Apr 6, 2018, at 1:30 AM, Stuart Cassoff <aa72 at bell.net> 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.
> >
> >>>> 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.
>
> Am I right in thinking that you haven't committed your build to the repository? I see no build.openbsd32x86 or build.openbsd64x64. If I am right, what is preventing committing back?
My work is in the form of an OpenBSD port. Here https://github.com/aryler/ostoobsd
When I have enough certainty in certain parts of the work I will (as I have already) submit them to OST in the form of pull request or patches and/or bug report.
Of course, anyone can, at their leisure, review my work and cherry-pick.
>
> > 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?
>
> curl is available natively in Mac OS X but whet isn't. wget is nicer than curl. Which does OpenBSD provide out of the box?
Neither.
OpenBSD's ftp(1) can do http transfers. This is not a recommendation.
>
> >
> > 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.
>
> No. One can also use a makefiles. Autoconf is not a necessity. If we had makefiles for Linux as we have for Mac OS X and Windows then they would be easy to clone. There would be ifdefs in platforms/unix/plugins/???/Makefiles (but maybe they are already).
>
> >
> > Lots of Makefiles and lots of ifdefs is surely the path to madness.
>
> Look, autoconf phase errors are mad anyway. The Mac OS X and Windows makefiles are not mad. Ergo the Linux ones wouldn't be either.
Ok.
>
> >
> >
> > 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