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

[Tobias Pape]

Hi 
> On 06.04.2018, at 10:30, 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.

Great! I have had a small go at that, too.

Eg, SqueakSSL on OpenBSD uses their libtls and so on.

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

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

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

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

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

¯\_(ツ)_/¯ I had the opposite experience…

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

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.


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