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

[Igor Stasenko]

On 1 June 2011 19:05, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 01.06.2011, at 18:55, Igor Stasenko wrote:
>
>> On 1 June 2011 18:47, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>> On 01.06.2011, at 18:43, Igor Stasenko wrote:
>>>
>>>> On 1 June 2011 18:26, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>>
>>>>> On 01.06.2011, at 18:24, Igor Stasenko wrote:
>>>>>
>>>>>> On 1 June 2011 18:20, Bert Freudenberg <bert at freudenbergs.de> 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.

> - Bert -
>

-- 
Best regards,
Igor Stasenko AKA sig.