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

Stuart Cassoff aa72 at bell.net
Fri Apr 6 09:54:20 UTC 2018


> ---------- Original Message ----------
> From: Tobias Pape <Das.Linux at gmx.de>
> Date: April 6, 2018 at 5:02 AM
> > On 06.04.2018, at 10:30, Stuart Cassoff <aa72 at bell.net> wrote:
> > 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.
> 
> Great! I have had a small go at that, too.
> 
> Eg, SqueakSSL on OpenBSD uses their libtls and so on.
> 

Great! I have yet to get deep into plugin building.

> > 
> > I can't say I'm enjoying seeing /bin/sh -> /bin/bash or any other gnuisms either existing or creeping in.
> 
> I tried to at least have bash in a way that works on OpenBSD, too
> (https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fe3620cdbfc82f5617cf4d9e364c2eabfe62695)

I don't think we fully agree on what to put at the top of the shell script. :D
Augh, I have patches for all those files! That's gonna take some siftin'.

> 
> To be frank, OpenBSDs pdksh is not really portable, either, and not too POSIX-friendly, too.

No problems on obsd with portable shell scripts.
I don't think there's anything in this project's shell scripts that explicitly need bash.
There's also dash and other shells to consider.

> 
> > 
> > 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.
> 
> How so?

>From a cursory look at the Makefiles I seem to remember seeing gnuish things.
It's on the list of things to check.
 
> 
> > 
> > Why curl *and* wget?
> 
> because most linuxes by default have wget installed and osx always has curl installed,
> and whoever wrote the script first came to decide. Not a good reason but an explanation of the status quo.

Thanks!

> 
> Hence this: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/plugins/UUIDPlugin/acinclude.m4
> Wherein I tried to make sure to have a working version.

The PostgreSQL people make the user supply the info. I've been thinking of following their lead.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=configure.in;h=da02a56ec661cd18d46807b358c0ee501eaeb015;hb=HEAD


I believe increasing this project's portability is worthwhile and achievable.


Stu


> 
> 
> Thanks for helping.
> 
> Best regards
> 	-Tobias
> 
> > 
> >> ---------- 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