[Mono-devel-list] corlib runtime versioning

[Paolo Molaro]

On 01/28/04 Ben Maurer wrote:
> Ok, maybe this approach to `fail safe building' is wrong. However, my
> larger point is `it should be easy for someone to maintain a build of
> Mono from cvs without much effort'

Yes, and it is: don't overwrite your working mono install: use a
different install prefix if you don't know what you're doing.

> Every time we tell someone `yeah, building from cvs is really hard, dont
> bother' we could be loosing a developer. So what would be really nice to

I didn't say that, in fact: if you did it's your fault, don't blame it
on 'we'.

> 1) A script such that to get a cvs build of Mono from scratch you do:
> wget http://go-mono.com/build-scripts/make-install.sh -q -O - | sh

Dude, looks like you have been trained in security, isn't it?
Besides, the script is already there in cvs, but you haven't spent any
time maintaining it, so it bitrotted. I know programming is harder than
writing emails, but so is life.

> The fact that multiple developers are telling people to do different
> things is a really bad sign. On IRC I see most people recommending

Yes, so how about if you stop proposing solutions you have neither
implemented nor tested?

> `fullbuild'; you recommend setting up some obscure build system.

Ok, it looks like you just want to troll. This is my last mail on the
subject, since no matter what it looks like you just want to play
and I have currently no time for that. Please don't bother replying.

> In short, by making the build hard, we may discourge a potential
> developer. When I got my build working for the first time, I was nearly

We are not making the build hard. There is a circular dependency in the
build and it's not going away. To break the dependency you need a
working mono install, that's it, so cvs builds should use a different 
prefix so not to overwrite it.
When you explain the real reason to people, they can understand and deal
with it. You tryng to push them to use some build script you haven't
written doesn't help, for the same reason the magic chainsaw doesn't
(it doesn't exist and if it exited it wouldn't work).
Of course there will always be a small percentage of people that don't
get it even after 10 times they overwrote the mono install and they'll
get frustrated, because they don't know why it failed. If people know
the reason, they get over it and will learn for the next time.

There is another issue: in the mcs build, the default is to use the new
corlib as soon as it is built to have a sort of forced check for people
that change it to test it. If the runtime needs updating you may get a
failure in the middle of the build and at this point some people panic
(probably the same kind of people that see compiler warnings and says
they are errors...). The solution is to update and compile the runtime
and continue the build later. We could change this default in a few
weeks when we start freezing for the release, though the real solution
would be to separate the corlib files from the rest of the assemblies.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better