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

Igor Stasenko siguctua at gmail.com
Wed Jun 1 18:51:11 UTC 2011

On 1 June 2011 21:01, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 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?

You can do it. I just don't see a compelling reason 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?
>>> 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.

Why its complicated? Download a tarball suitabe for your platform and
build vm.. or package it into distro/whatever.
How it is more complicated?

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

Sorry, but it makes no sense. Why they need to tweak config files at
wrong place (in generated files), without changing an appropriate
If something is not working or needs to be changed, then it should be
changed in configuration, but not tweaking makefiles.
Maybe its easier for those who never use smalltalk (but then why they
even care to maintain VM for us? or.. how you can maintain things,
when you know nothing about them?).

Because configuration is not just about target platform, it is also
about what kind of VM you wanna build, what plugins you wanna to
include by default etc etc..
And to bring everything together there is a single configuration file,
written in smalltalk, which generating makefiles.

And because we need a feedback. If distro maintainer will tweak
something, without feedback to us, then it is not an open-source
It is a segregated islands of developpers, each living with his own
problems, without any communication between them.
So, yes.. its about audience: communication and joint efforts.
Because smalltalkers when they will have problems with VM built from
distro will come here and start asking questions, why it doesn't works
for me, but works for you. And your answer will be: ask the guy who
tweaked makefiles for your distro..
Sorry, i don't like such model.

Best regards,
Igor Stasenko AKA sig.

More information about the Vm-dev mailing list