Updating your build? (was: Re: [ANNOUNCE] GARNOME 2.17.91 -- "go go gadget garnome")
- From: guenther <guenther rudersport de>
- To: garnome-list gnome org
- Subject: Updating your build? (was: Re: [ANNOUNCE] GARNOME 2.17.91 -- "go go gadget garnome")
- Date: Tue, 20 Feb 2007 18:56:10 +0100
> What is the best way to upgrade from one release to the next?
As Stef and Peter already pointed out, there is none. Well, there
definitely is no "best way" to do this anyway... ;)
There are hacks to rebuild parts (read update) only. However, this is
*not* fail proof at all. FWIW, between releases both Joseph and me tend
to rebuild updates only, to check buildability and catch most issues as
soon as possibly. However, we have seen lots of strangeness due to such
mixing already [1] [2]. Short before a release (as well as every now and
then) we usually build fresh to catch some remaining issues.
Actually, building updated garballs isn't hard -- IF and only if there
is no build magic involved. This of course is only possible, if you keep
your build tree, and it is more complicated when trying this stunt using
GARNOME tarball releases, rather than SVN.
The most glaring issue here is the GAR build system itself, which
defines dependencies in a tree structure. When rebuilding a lib, it may
be necessary to rebuild the apps that depend on it, too. Including
cascaded deps of deps...
Since questions like this do come up occasionally (and I am actually
using rebuild techniques), I have been thinking about this issue a
couple of times already. This is a rather tough one, but maybe some fine
day I'll come up with a user-consumable hack. :)
For best smoketesting and ensuring a sane build, especially when you're
using GARNOME tarball releases, building fresh definitely is the way to
go. Just use versioned prefixes.
guenther
[1] Story: Seahorse once built when running 'make install' twice, due
to upstream Makefile.in issues. The first run failed, but already
created a necessary dep for the second run, which then built fine.
Building that very tarball with an older already installed one
finished "successfully" in the first run, cause it picked up an old
lib...
[2] When it comes to rebuilding libs lower in the stack, all kinds of
strange build issues, like undefined symbols and even unexpected UI
behavior when using the build has happened in the past. Breakage in
both directions happened: Failed builds with older stuff around, as
well as not caught build failures when building fresh.
--
char *t="\10pse\0r\0dtu\0 ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]