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

[Nicolas Cellier]

2018-04-02 16:00 GMT+02:00 Holger Freyther <holger at freyther.de>:

>
>
>
> > On 2. Apr 2018, at 14:51, Nicolas Cellier <nicolas.cellier.aka.nice@
> 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...
>
>
Hi Holger,


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

me neither, it's super easy to clone those mvm & Makefile and then
impossible to manage all the copies...


>
> * 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?
>
> Thanks for the hints, the problem is that it works well on my debian, and
that such remote debugging is a hurdle for me...


>
> [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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180402/542d6f68/attachment.html>