Fwd: [Bug 791243] [NEW] squeak-vm version 1:4.4.7.2357-1 failed to build on armel

> From: Ricardo Salveti <[hidden email]>
> Date: 1. Juni 2011 14:51:46 MESZ
> To: [hidden email]
> Subject: [Bug 791243] [NEW] squeak-vm version 1:4.4.7.2357-1 failed to build on armel
> Reply-To: Bug 791243 <[hidden email]>
>
> Public bug reported:
>
> squeak-vm version 1:4.4.7.2357-1 failed to build on armel
> Link to failed build: https://launchpad.net/ubuntu/+source/squeak-vm/1:4.4.7.2357-1/+build/2493539
>
> Direct link to the build log: https://launchpad.net/ubuntu/+source
> /squeak-vm/1:4.4.7.2357-1/+build/2493539/+files/buildlog_ubuntu-oneiric-
> armel.squeak-vm_1%3A4.4.7.2357-1_FAILEDTOBUILD.txt.gz
>
> This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
> Excerpt 2473 lines into the build log:
>
> [  9%] Built target FloatArrayPlugin
> make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> Scanning dependencies of target FloatMathPlugin
> make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> [ 10%] Building C object FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o
> cc1: error: unrecognized command line option '-mno-fused-madd'
> make[3]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o] Error 1
> make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> make[2]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/all] Error 2
> make[2]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> make: *** [build-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> ******************************************************************************
> Build finished at 20110513-2052
> FAILED [dpkg-buildpackage died]
> Purging chroot-autobuild/build/buildd/squeak-vm-4.4.7.2357
>
> ** Affects: squeak-vm (Ubuntu)
>     Importance: Undecided
>         Status: New
>
>
> ** Tags: arm-porting-queue ftbfs
>
> --
> You received this bug notification because you are subscribed to squeak-
> vm in Ubuntu.
> https://bugs.launchpad.net/bugs/791243
>
> Title:
>  squeak-vm version 1:4.4.7.2357-1 failed to build on armel
>
> Status in “squeak-vm” package in Ubuntu:
>  New
>
> Bug description:
>  squeak-vm version 1:4.4.7.2357-1 failed to build on armel
>  Link to failed build: https://launchpad.net/ubuntu/+source/squeak-vm/1:4.4.7.2357-1/+build/2493539
>
>  Direct link to the build log: https://launchpad.net/ubuntu/+source
>  /squeak-vm/1:4.4.7.2357-1/+build/2493539/+files/buildlog_ubuntu-
>  oneiric-armel.squeak-vm_1%3A4.4.7.2357-1_FAILEDTOBUILD.txt.gz
>
>  This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
>  Excerpt 2473 lines into the build log:
>
>  [  9%] Built target FloatArrayPlugin
>  make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
>  Scanning dependencies of target FloatMathPlugin
>  make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
>  make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
>  [ 10%] Building C object FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o
>  cc1: error: unrecognized command line option '-mno-fused-madd'
>  make[3]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o] Error 1
>  make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
>  make[2]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/all] Error 2
>  make[2]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
>  make[1]: *** [all] Error 2
>  make[1]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
>  make: *** [build-stamp] Error 2
>  dpkg-buildpackage: error: debian/rules build gave error exit status 2
>  ******************************************************************************
>  Build finished at 20110513-2052
>  FAILED [dpkg-buildpackage died]
>  Purging chroot-autobuild/build/buildd/squeak-vm-4.4.7.2357

>
>
> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>
>>
>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>
>> just kill that option
>
> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>

> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>
>>
>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>
>>>
>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>
>>> just kill that option
>>
>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>
> Maybe.
> But you know, i took a different approach:
> - generate separate cmake file per each target platform, tested &
> proved to be working on that platform.

>
> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>
>> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>
>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>
>>>>
>>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>>
>>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>>
>>>> just kill that option
>>>
>>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>>
>> Maybe.
>> But you know, i took a different approach:
>> - generate separate cmake file per each target platform, tested &
>> proved to be working on that platform.
>
> Nice. We still need a single source tar ball for unix

> On 1 June 2011 18:47, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>>
>>> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>>
>>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>>
>>>>>
>>>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>>>
>>>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>>>
>>>>> just kill that option
>>>>
>>>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>>>
>>> Maybe.
>>> But you know, i took a different approach:
>>> - generate separate cmake file per each target platform, tested &
>>> proved to be working on that platform.
>>
>> Nice. We still need a single source tar ball for unix
>
> Why? There is so many unizes, that you can't guarantee that same
> source tarball will be working everywhere. So why not abandon this
> idea?
> Hudson generates a single tarball per each target:
>  - one for linux
>  - one for mac
>  - one for windows
>  - add yours

>
>> - how do you switch between the different architectures?
>>
>
> There is no any swtich.
> You picking a concrete CMakeVMMaker configuration, suitable (and made)
> for target platform, to generate sources and cmake files.
> And then you just build VM.
> The generated files contain an explicit instructions what to include
> into build and what options to use.
> There is no any if(x) then (y) else (z) in generated files.
> It is responsibility of configuration to know all those x,y,z and sort them out.
>
>> - Bert -
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> On 1 June 2011 18:47, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>>
>>> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>>
>>>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>>>
>>>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>>>
>>>>> just kill that option
>>>>
>>>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>>>
>>> Maybe.
>>> But you know, i took a different approach:
>>> - generate separate cmake file per each target platform, tested &
>>> proved to be working on that platform.
>>
>> Nice. We still need a single source tar ball for unix
>
> Why?

> Hudson generates a single tarball per each target:
> - one for linux
> - one for mac
> - one for windows
> - add yours
>
>
>> - how do you switch between the different architectures?
>>
>
> There is no any swtich.
> You picking a concrete CMakeVMMaker configuration, suitable (and made)
> for target platform, to generate sources and cmake files.
> And then you just build VM.
> The generated files contain an explicit instructions what to include
> into build and what options to use.
> There is no any if(x) then (y) else (z) in generated files.
> It is responsibility of configuration to know all those x,y,z and sort them out.

>
> On 01.06.2011, at 18:55, Igor Stasenko wrote:
>
>> On 1 June 2011 18:47, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>>>
>>>> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>>>>
>>>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>>>
>>>>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>>>>
>>>>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>>>>
>>>>>> just kill that option
>>>>>
>>>>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>>>>
>>>> Maybe.
>>>> But you know, i took a different approach:
>>>> - generate separate cmake file per each target platform, tested &
>>>> proved to be working on that platform.
>>>
>>> Nice. We still need a single source tar ball for unix
>>
>> Why?
>
> Because that's what distributions use. Like Ubuntu (see the bug report I forwarded).

>
>> Hudson generates a single tarball per each target:
>> - one for linux
>> - one for mac
>> - one for windows
>> - add yours
>>
>>
>>> - how do you switch between the different architectures?
>>>
>>
>> There is no any swtich.
>> You picking a concrete CMakeVMMaker configuration, suitable (and made)
>> for target platform, to generate sources and cmake files.
>> And then you just build VM.
>> The generated files contain an explicit instructions what to include
>> into build and what options to use.
>> There is no any if(x) then (y) else (z) in generated files.
>> It is responsibility of configuration to know all those x,y,z and sort them out.
>
> So you are suggesting to hand-code the makefiles again? Everybody needs to tweak them to fit their machine? You can't be serious.
>

>
>
>
> Begin forwarded message:
>
> > From: Ricardo Salveti <[hidden email]>
> > Date: 1. Juni 2011 14:51:46 MESZ
> > To: [hidden email]
> > Subject: [Bug 791243] [NEW] squeak-vm version 1:4.4.7.2357-1 failed to build on armel
> > Reply-To: Bug 791243 <[hidden email]>
> >
> > Public bug reported:
> >
> > squeak-vm version 1:4.4.7.2357-1 failed to build on armel
> > Link to failed build: https://launchpad.net/ubuntu/+source/squeak-vm/1:4.4.7.2357-1/+build/2493539
> >
> > Direct link to the build log: https://launchpad.net/ubuntu/+source
> > /squeak-vm/1:4.4.7.2357-1/+build/2493539/+files/buildlog_ubuntu-oneiric-
> > armel.squeak-vm_1%3A4.4.7.2357-1_FAILEDTOBUILD.txt.gz
> >
> > This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
> > Excerpt 2473 lines into the build log:
> >
> > [  9%] Built target FloatArrayPlugin
> > make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> > Scanning dependencies of target FloatMathPlugin
> > make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> > make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> > [ 10%] Building C object FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o
> > cc1: error: unrecognized command line option '-mno-fused-madd'
> > make[3]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o] Error 1
> > make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> > make[2]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/all] Error 2
> > make[2]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> > make: *** [build-stamp] Error 2
> > dpkg-buildpackage: error: debian/rules build gave error exit status 2
> > ******************************************************************************
> > Build finished at 20110513-2052
> > FAILED [dpkg-buildpackage died]
> > Purging chroot-autobuild/build/buildd/squeak-vm-4.4.7.2357
> >
> > ** Affects: squeak-vm (Ubuntu)
> >     Importance: Undecided
> >         Status: New
> >
> >
> > ** Tags: arm-porting-queue ftbfs
> >
> > --
> > You received this bug notification because you are subscribed to squeak-
> > vm in Ubuntu.
> > https://bugs.launchpad.net/bugs/791243
> >
> > Title:
> >  squeak-vm version 1:4.4.7.2357-1 failed to build on armel
> >
> > Status in ?squeak-vm? package in Ubuntu:
> >  New
> >
> > Bug description:
> >  squeak-vm version 1:4.4.7.2357-1 failed to build on armel
> >  Link to failed build: https://launchpad.net/ubuntu/+source/squeak-vm/1:4.4.7.2357-1/+build/2493539
> >
> >  Direct link to the build log: https://launchpad.net/ubuntu/+source
> >  /squeak-vm/1:4.4.7.2357-1/+build/2493539/+files/buildlog_ubuntu-
> >  oneiric-armel.squeak-vm_1%3A4.4.7.2357-1_FAILEDTOBUILD.txt.gz
> >
> >  This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
> >  Excerpt 2473 lines into the build log:
> >
> >  [  9%] Built target FloatArrayPlugin
> >  make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> >  Scanning dependencies of target FloatMathPlugin
> >  make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> >  make[3]: Entering directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> >  [ 10%] Building C object FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o
> >  cc1: error: unrecognized command line option '-mno-fused-madd'
> >  make[3]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/build/buildd/squeak-vm-4.4.7.2357/unix/src/vm/intplugins/FloatMathPlugin/FloatMathPlugin.c.o] Error 1
> >  make[3]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> >  make[2]: *** [FloatMathPlugin/CMakeFiles/FloatMathPlugin.dir/all] Error 2
> >  make[2]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> >  make[1]: *** [all] Error 2
> >  make[1]: Leaving directory `/build/buildd/squeak-vm-4.4.7.2357/build-tree'
> >  make: *** [build-stamp] Error 2
> >  dpkg-buildpackage: error: debian/rules build gave error exit status 2
> >  ******************************************************************************
> >  Build finished at 20110513-2052
> >  FAILED [dpkg-buildpackage died]
> >  Purging chroot-autobuild/build/buildd/squeak-vm-4.4.7.2357

>
> On 1 June 2011 19:05, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 01.06.2011, at 18:55, Igor Stasenko wrote:
>>
>>> On 1 June 2011 18:47, Bert Freudenberg <[hidden email]> wrote:
>>>>
>>>> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>>>>
>>>>> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>>>>>
>>>>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>>>>
>>>>>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>>>>>
>>>>>>> just kill that option
>>>>>>
>>>>>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>>>>>
>>>>> Maybe.
>>>>> But you know, i took a different approach:
>>>>> - generate separate cmake file per each target platform, tested &
>>>>> proved to be working on that platform.
>>>>
>>>> Nice. We still need a single source tar ball for unix
>>>
>>> Why?
>>
>> Because that's what distributions use. Like Ubuntu (see the bug report I forwarded).
>
> Wait. If you have a distro of some application for Ubuntu, you don't
> assume that it will work on other unixes, right?
> So, tell me, why there is a pressing need to have a single VM tarball
> which can be used on all existing unixes without problems?

>>
>>> There is so many unizes, that you can't guarantee that same
>>> source tarball will be working everywhere. So why not abandon this
>>> idea?
>>
>> Okay, then we need at least a tarball for Linux. I just thought it's not that much harder to make it work on different unixes than different Linuxes. At least that's the assumption we have been operating under. There is only a single tarball release for all unices, AFAIK.
>
> Yes. For Squeak VMs.
>
> Look, i don't wanna argue about that. Just wanted to point out that in
> CMakeVMMaker & Hudson, we taken a different approach (one tarball per
> target) , to separate the problem space,
> and let developers to fix problems for their concrete platform,
> without touching/modifying same files by introducing magic
> incarnations everywhere (if (x) then (y) else (z) ).

>>> Hudson generates a single tarball per each target:
>>> - one for linux
>>> - one for mac
>>> - one for windows
>>> - add yours
>>>
>>>
>>>> - how do you switch between the different architectures?
>>>>
>>>
>>> There is no any swtich.
>>> You picking a concrete CMakeVMMaker configuration, suitable (and made)
>>> for target platform, to generate sources and cmake files.
>>> And then you just build VM.
>>> The generated files contain an explicit instructions what to include
>>> into build and what options to use.
>>> There is no any if(x) then (y) else (z) in generated files.
>>> It is responsibility of configuration to know all those x,y,z and sort them out.
>>
>> So you are suggesting to hand-code the makefiles again? Everybody needs to tweak them to fit their machine? You can't be serious.
>>
> Wait, when you placing a branches in makefiles, like if(x) then (y) else (z),
> does it less hand-code, than using two smalltalk classes per target ,
> where in one you using option(s) 'y', and in another class , you using
> option(s) 'z' , which then will generate cmake files?
>
> You have to do it (hand-coding) anyways, but in CMakeVMmaker configs
> this knowledge (what to use and when) are captured and grouped
> together in a single class, which denoting your target.
> So, if something wrong with build, you know where to go. Instead of
> groking trough multiple files and includes and .c headers with tons of
> #ifdefs and #defines,
> and modifying them each time you need to add another branch.
>
> By analogy, in sources we have a unix, win32, and mac os subdirs.
> So, this reflects same approach: instead of having single
> platforms/all
>
> files, which suitable for building on all platforms, we have
>
> platforms/os1
> platforms/os2
> ...
> to separate the problem space.

>
>
> On 01.06.2011, at 19:35, Igor Stasenko wrote:
>
>>
>> On 1 June 2011 19:05, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 01.06.2011, at 18:55, Igor Stasenko wrote:
>>>
>>>> On 1 June 2011 18:47, Bert Freudenberg <[hidden email]> wrote:
>>>>>
>>>>> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>>>>>
>>>>>> On 1 June 2011 18:26, Bert Freudenberg <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>>>>>
>>>>>>>> On 1 June 2011 18:20, Bert Freudenberg <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>>> cc1: error: unrecognized command line option '-mno-fused-madd'
>>>>>>>>
>>>>>>>> just kill that option
>>>>>>>
>>>>>>> ... but only if the compiler does not support it, right? I guess the CMakefile needs to be more intelligent about it.
>>>>>>>
>>>>>> Maybe.
>>>>>> But you know, i took a different approach:
>>>>>> - generate separate cmake file per each target platform, tested &
>>>>>> proved to be working on that platform.
>>>>>
>>>>> Nice. We still need a single source tar ball for unix
>>>>
>>>> Why?
>>>
>>> Because that's what distributions use. Like Ubuntu (see the bug report I forwarded).
>>
>> Wait. If you have a distro of some application for Ubuntu, you don't
>> assume that it will work on other unixes, right?
>> So, tell me, why there is a pressing need to have a single VM tarball
>> which can be used on all existing unixes without problems?
>
> I don't know any other project that has separate source tarballs for each unix. What is so special about the Squeak VM that we could not possibly do it?
>

>>>
>>>> There is so many unizes, that you can't guarantee that same
>>>> source tarball will be working everywhere. So why not abandon this
>>>> idea?
>>>
>>> Okay, then we need at least a tarball for Linux. I just thought it's not that much harder to make it work on different unixes than different Linuxes. At least that's the assumption we have been operating under. There is only a single tarball release for all unices, AFAIK.
>>
>> Yes. For Squeak VMs.
>>
>> Look, i don't wanna argue about that. Just wanted to point out that in
>> CMakeVMMaker & Hudson, we taken a different approach (one tarball per
>> target) , to separate the problem space,
>> and let developers to fix problems for their concrete platform,
>> without touching/modifying same files by introducing magic
>> incarnations everywhere (if (x) then (y) else (z) ).
>
> Yes, and I'm talking about what we officially release to the open-source community at large. It took a lot of effort to get the VM into various Linux distros. We should not make it more complicated for the maintainers, we should be thankful.
>

>>>> Hudson generates a single tarball per each target:
>>>> - one for linux
>>>> - one for mac
>>>> - one for windows
>>>> - add yours
>>>>
>>>>
>>>>> - how do you switch between the different architectures?
>>>>>
>>>>
>>>> There is no any swtich.
>>>> You picking a concrete CMakeVMMaker configuration, suitable (and made)
>>>> for target platform, to generate sources and cmake files.
>>>> And then you just build VM.
>>>> The generated files contain an explicit instructions what to include
>>>> into build and what options to use.
>>>> There is no any if(x) then (y) else (z) in generated files.
>>>> It is responsibility of configuration to know all those x,y,z and sort them out.
>>>
>>> So you are suggesting to hand-code the makefiles again? Everybody needs to tweak them to fit their machine? You can't be serious.
>>>
>> Wait, when you placing a branches in makefiles, like if(x) then (y) else (z),
>> does it less hand-code, than using two smalltalk classes per target ,
>> where in one you using option(s) 'y', and in another class , you using
>> option(s) 'z' , which then will generate cmake files?
>>
>> You have to do it (hand-coding) anyways, but in CMakeVMmaker configs
>> this knowledge (what to use and when) are captured and grouped
>> together in a single class, which denoting your target.
>> So, if something wrong with build, you know where to go. Instead of
>> groking trough multiple files and includes and .c headers with tons of
>> #ifdefs and #defines,
>> and modifying them each time you need to add another branch.
>>
>> By analogy, in sources we have a unix, win32, and mac os subdirs.
>> So, this reflects same approach: instead of having single
>> platforms/all
>>
>> files, which suitable for building on all platforms, we have
>>
>> platforms/os1
>> platforms/os2
>> ...
>> to separate the problem space.
>
> It's a question of the audience. If Smalltalk hackers build a VM config tool for themselves, then of course hacking it into VMMaker makes sense. But the audience I'm talking are the maintainers in the various Linux distros. They will not fire up VMMaker and generate a specific config for their needs. They need to be able to tweak a config file. And it is for sure easier to tweak a single config file than a gazillion pre-generated ones for each possible combination of x, y, and z.

>
> Probably a new Unix VM build will be needed in order to address this.
>
> Background on the FloatMathPlugin issues is at<http://bugs.squeak.org/view.php?id=7592>.
>
> Ian removed the problematic '-mno-fused-madd' option as of SVN revision 2374
>    <http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/unix/plugins/FloatMathPlugin/config.cmake?rev=2374&view=markup>
>
> The Ubuntu bug report below is for sources at the 4.4.7.2357 level (SVN 2357),
> so that tarball does not include the fix that Ian applied in SVN 2374.
>
> I will copy Ian on this note so that he is aware.
>
> Dave