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

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 3 12:30:06 UTC 2018


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?



> 
> Dave
> 


More information about the Vm-dev mailing list