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

David T. Lewis lewis at mail.msen.com
Tue Apr 3 13:23:37 UTC 2018


On Tue, Apr 03, 2018 at 05:30:06AM -0700, Eliot Miranda wrote:
>  
> Hi David,
> 
> > On Apr 2, 2018, at 8:11 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > 
> >> On Mon, Apr 02, 2018 at 03:54:15PM -0700, Eliot Miranda wrote:
> >> 
> >> Hi Holger,
> >> 
> >>>> On Apr 2, 2018, at 7:00 AM, Holger Freyther <holger at freyther.de> wrote:
> >>>> 
> >>>> On 2. Apr 2018, at 14:51, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> >>>> 
> >>>> Gah!
> >>>> 
> >>>> despite my stuttutututter command:
> >>>>   CC=clang ./configure CC=clang
> >>>> the travis build is completely ignoring the directives and keep using gcc
> >>>> 
> >>>> See:
> >>>> https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361174043 <https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/361174043>
> >>>> 
> >>>> I suspect that it's lack of clean build, but not sure...
> >>>> 
> >>>> Building OpenSmalltalk VM in /home/travis/build/OpenSmalltalk/opensmalltalk-vm/build.linux32x86/pharo.sista.spur/build.itimerheartbeat...
> >>>> <>Re-exec as x86
> >>>> <>clean? ok but this isn't safe!!
> >>>> Or would the clang compiler be absent?
> >>>> Or what?
> >>>> 
> >>>> It ain't fun...
> >>> 
> >>> The cost of abstraction... I am not a fan of the "build" scripts (a lot of code cloning for what[1] gain?) and the travis logs don't show us the invocation of the actual commands.
> >> 
> >> The complexity is due to the arcane nature of the Linux/Unix build system and its use of autoconf and several scripts to generate makefiles.  I have been saying for years that we need to rewrite the Linux build system to use convention makefiles as per Andreas' Windows makefiles and my subsequent Mac OS Makefiles.  I rewrote the Mac OS build system to use makefiles (*) and you'll notice that
> >> - all share a small suite of makefiles in build.macosXXX/common
> >> - all have a single top-level Makefile that defines the vm variant (the vm source directory) and some branding
> >> - all mvm scripts under build.macosXXX are identical and serve only to invoke make with the three variants, production, assert & debug VMs
> > 
> > Hi Eliot,
> > 
> > To be perfectly honest, I do not know what it meant by "we need to rewrite the Linux
> > build system to use conventional makefiles". Using makefiles would be a given for any
> > build system on unix/Linux, the differences (and pain points) are in the configuration
> > step. Regardless of whether you use autoconf or CMake or something else, we would still
> > need something to specify the environment in which the makefile is operating. In other
> > words, we need a build/config.h to specify the things that the makefile does not know
> > about. I am pretty sure I am misunderstanding something in this discussion, but I am
> > comfused and I may as well admit it.
> 
> I'm feeling beaten down.  Perhaps you could read the code?  Compare what's in
>     platforms/unix/config
> with what's in
>     build.macos32x86/common
>     build.macos64x64/common
>     build.win32x86/common
>     build.win64x64/common
> 
> And then think about the "necessary configure step".  To what extent does it make sense to run a configure step on a build machine that makes a binary that is downloaded and used on machines that may differ markedly from that build machine?
>

Hi Eliot,

First an apology - this was not a very good time to be asking a dumb question.

Yes I did look at the code, but probably not closely enough. I will do so.

Dave



More information about the Vm-dev mailing list