[Mono-devel-list] corlib runtime versioning

Ben Maurer bmaurer at users.sourceforge.net
Wed Jan 28 09:10:46 EST 2004


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'

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
see is the following:

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

2) For this script to make a `update-build.sh' script that 99% of the
time will be able to build mono by doing:

`./update-build.sh'

The fact that multiple developers are telling people to do different
things is a really bad sign. On IRC I see most people recommending
`fullbuild'; you recommend setting up some obscure build system.

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
on the verge of giving up and erasing the new Redhat9 install I had made
to go back to Windows. Luckly, I figured out the system quickly enough
that this did not happen. However, I would bet that many people have
just given up and we will never see the great code they could have
written.

I do love the story of the Magic Chainsaw. We need build documents that
read as well as this :-).

-- Ben

On Wed, 2004-01-28 at 07:10, Paolo Molaro wrote:
> On 01/23/04 Ben Maurer wrote:
> > I don't really understand why you say we cant do it. The way someone
> > should install a new build is:
> > 
> > 1) install the new corlib
> > 2) install the new mono
> 
> Only in your limited corner/view of the world. There is a surprisingly
> small number of people that should do that: people working from cvs.
> People installing from snapshots or tarballs just need to do make
> install and people using distribution packages don't need to do anything
> of the sorts. Note that the last two sets of people are easily 3 orders
> of magnitude bigger than the people that should follow your suggestion.
> 
> > So, when we are at stage 2, the *new* mono should return a `0' when
> > doing the version check. This process can be done with `make fullbuild'.
> 
> As long as the check is not done by default it's fine, because by
> default it's wrong and if you'd spend one minute thinking about it you'd
> realize it.
> 
> > Also, we could allow someone to run:
> > make install SANITY_CHECKS=false
> > 
> > to override the safeguard in non-standard cases.
> 
> Yes, too bad your concept of standard is the wrong one.
> 
> > The reason why I support having it in the build is that often people
> > will install the runtime first before building corlib. This puts them in
> > a really hard position, as they are not able to get out of it without
> > the assistance of a monocharge.
> 
> People that use packages, tarballs and snapshots don't need the check.
> People that use cvs can screwup the installation in a million ways: they
> are supposed to always keep a working mono install separate from the cvs
> install, that way there is no issue. If you want to add the check to
> make fullbuild, it's ok, as long as you and other people realize that
> make fullbuild is just a hack and it may not work. The right thing to do
> is to explain people they should not overwrite their working mono
> install.
> If you need to cut the branch of a tree, you better not sit on that
> branch. You're telling people: use my magic chainsaw and even if you cut
> the branch you're sitting on, you won't fall. And they go only to
> realize the magic chainsaw doesn't work when it's too late.
> Just sit on one branch (keep a working mono install in a different
> prefix) when you need to cut another (make install a new mono version).
> 
> lupus




More information about the Mono-devel-list mailing list