Why the hell directives for compiling with clang were not taken into account

> ---------- Original Message ----------
> From: Eliot Miranda <[hidden email]>
> Date: April 3, 2018 at 4:31 PM
>
>
>  Hi Subbu,
>
> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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

> On 06.04.2018, at 10:30, Stuart Cassoff <[hidden email]> 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.

>
>> ---------- Original Message ----------
>> From: Eliot Miranda <[hidden email]>
>> Date: April 3, 2018 at 4:31 PM
>>
>>
>> Hi Subbu,
>>
>> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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

> ---------- Original Message ----------
> From: Tobias Pape <[hidden email]>
> Date: April 6, 2018 at 5:02 AM
> > On 06.04.2018, at 10:30, Stuart Cassoff <[hidden email]> 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.
>

>
>
> Thanks for helping.
>
> Best regards
> -Tobias
>
> >
> >> ---------- Original Message ----------
> >> From: Eliot Miranda <[hidden email]>
> >> Date: April 3, 2018 at 4:31 PM
> >>
> >>
> >> Hi Subbu,
> >>
> >> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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
>

> On Apr 6, 2018, at 1:30 AM, Stuart Cassoff <[hidden email]> 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.

>
>
> 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 <[hidden email]>
>> Date: April 3, 2018 at 4:31 PM
>>
>>
>> Hi Subbu,
>>
>>> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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

> ---------- Original Message ----------
> From: Eliot Miranda <[hidden email]>
> Date: April 6, 2018 at 9:55 AM
>
>
>  
> Hi Stuart,
>
> > On Apr 6, 2018, at 1:30 AM, Stuart Cassoff <[hidden email]> 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.
>

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

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

>
> >
> >
> > 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 <[hidden email]>
> >> Date: April 3, 2018 at 4:31 PM
> >>
> >>
> >> Hi Subbu,
> >>
> >>> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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

> ---------- Original Message ----------
> From: Tobias Pape <[hidden email]>
> Date: April 6, 2018 at 5:02 AM
>
>
> Hi
> > On 06.04.2018, at 10:30, Stuart Cassoff <[hidden email]> 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 <[hidden email]>
> >> Date: April 3, 2018 at 4:31 PM
> >>
> >>
> >> Hi Subbu,
> >>
> >> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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
>

>
>
> Stu
>
>> ---------- Original Message ----------
>> From: Tobias Pape <[hidden email]>
>> Date: April 6, 2018 at 5:02 AM
>>
>>
>> Hi
>>> On 06.04.2018, at 10:30, Stuart Cassoff <[hidden email]> 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 <[hidden email]>
>>>> Date: April 3, 2018 at 4:31 PM
>>>>
>>>>
>>>> Hi Subbu,
>>>>
>>>> On Tue, Apr 3, 2018 at 10:35 AM, K K Subbu <[hidden email]> 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
>>