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

[Nicolas Cellier]

So with the help of Ben and Tobias, I can build linux32x86 pharo.sista.spur
on travis now
The right incantation is in .travis.yml thru compiler:clang directive,
because it later export CC=clang in root build shell.

Failing to do so exports a CC=gcc default, so overriding via configure
command args is not enough, it must be repeated for make and everywhere I
did not look yet ;)
It's better to follow the "standard" way.

I'm still waiting the rest of the build to finish, then I will emit a PR.
There is an alternative of using another version of gcc by Tobias which
seems to work also.

Anyway, all i did was a quick hack.
Because the mvm is duplicated in other directories (assert and debug
version...), there will be more trouble if we not fix it everywhere.
Or maybe the configure CC=clang argument is not required?




2018-04-02 19:38 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

> Hi Tobias,
> Ah, that's enlightning !
>
> 2018-04-02 19:12 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:
>
>>
>>
>> > On 02.04.2018, at 15:51, Nicolas Cellier <nicolas.cellier.aka.nice at gmai
>> l.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
>> >
>>
>> Have you seen this?
>>         https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/
>> 361174043#L448
>>
>> OTOH, I did it that way:
>>         https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/
>> krono/upgrade-gcc#diff-f36a4fd868404ca84d806453aabb6f3bR65
>>
>>
>>
>> > I suspect that it's lack of clean build, but not sure...
>> >
>> > Building OpenSmalltalk VM in /home/travis/build/OpenSmallta
>> lk/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...
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180402/a25e14be/attachment.html>