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

[Bert Freudenberg]

On 01.06.2011, at 19:35, Igor Stasenko wrote:

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

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.

- Bert -