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

[Eliot Miranda]

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
Indeed were it not for no symbolic link support for git/svn et al on windows the mvm script would be a symbolic link to a single file

Note that using the makefiles approach eliminates the separate build directories for production, assert & debug VMs


(*) rewriting the Mac OS build system to use makefiles was the path of least resistance when adding building of 64-bit Spur VMs because Xcode project files offer no abstraction and no sharing and are much much worse to edit than the Linux mvm scripts


So instead of bashing the awful little bud build system can we rewrite them together follow the windows and Mac OS scheme?  We would likely end up with one set of makefiles for all Linux builds apart from a separate rules file (compilation flags etc) per platform per word size.  And of course there would be a single mvm script and one would never need to run autoconfig and hence get the phase errors that result from some settings between my made when configure gets built, said me getting made when configure is run and yet others being made when make is run.

> 
> * One would need to pass CC to configure and make
> * But even for configure CC=clang seems to go missing (https://api.travis-ci.org/v3/job/361174043/log.txt): "checking whether gcc -std=gnu99 is Clang... no"
> 
> 
> Try executing the script with shell tracing on "sh -x ./build..." and see if CC is being passed a long? And cat config.log to see which compiler was used during the configuration step?
> 
> 
> [1] I have worked with ARM, MIPS, PowerPC, x86 CPUs in my career and I know no other project that needs such build scripts to support different architectures and build flags...