Re: GNOME 2.2 screenshots
- From: Mathias Hasselmann <mathias hasselmann gmx de>
- To: Havoc Pennington <hp redhat com>
- Cc: "tromey redhat com" <tromey redhat com>, Jeff Waugh <jdub perkypants org>, "desktop-devel-list gnome org" <desktop-devel-list gnome org>, Alexandre Duret-Lutz <duret_g epita fr>
- Subject: Re: GNOME 2.2 screenshots
- Date: Mon, 8 Jul 2002 10:02:11 +0000 (GMT)
On 7 Jul 2002, Havoc Pennington wrote:
>
> Tom Tromey <tromey redhat com> writes:
> > Havoc> Ideally the automake-1.6 package would not even contain a thing
> > Havoc> called simply "automake" since it just encourages bugs of the
> > Havoc> form "I got the wrong automake"
> >
> > I don't think we'll do this. Instead just put AUTOMAKE_OPTIONS = 1.6
> > into the top-level Makefile.am of any converted package. Then you'll
> > get an error if you accidentally use 1.4.
>
> That makes sense.
>
> > Havoc> If we can't do parallel install, we can't migrate to new
> > Havoc> automake module-by-module. That means that as soon as we move
> > Havoc> to 1.6 for HEAD, then people can't work on the stable branch
> > Havoc> anymore, unless they have two totally different build prefixes,
> > Havoc> with their own copies of autotools.
> >
> > I don't understand. Is this somehow related to the automatic rebuild
> > rules?
>
> No. It's simply that we have to move all thousand-plus people building
> out of CVS, and the dozens of modules they're building, as a whole.
> Because without parallel install, people can only have one version of
> automake installed. We can't change just one module to 1.6, because
> users would then need to switch automakes, build that module, and
> switch automakes back. This is why we are still using 1.4, because
> changing all this at once is just too hard.
>
> If we could switch each module on its own time, we would have dumped
> 1.4 ages and ages ago. Because switching would be really easy, since
> we wouldn't have to cause any pain/breakage in order to do it; we'd
> just say "you have to install all the automakes" and then things would
> Just Work for people and the packages could use a mix of automakes.
>
> Maybe it's too late to fix; aside from renaming automake to
> automake-1.4, there's the /usr/share/aclocal conflict issue, and all
> that. I dunno.
Pardon? Pathnames? If that's the entire problem: Paths are easy to
adjust - hey, we have the sources! Uh... And aren't the paths uses by
those tools adjustable by the configure script of those tools? Well, and
autoconf (which handles all the .m4 melange for autmake even knows about
an --autoconf-dir switch, suiteable to select the aclocal directory to
use...
Well IHMO it should be enough to create a set of trivial wrapper
scripts (instead of all this symlink/renaming voodoo) which just reads
some environment variables to get arround the entire problem. Let's take
this script as an example:
$ cat /usr/bin/automake
#!/bin/bash
scriptname="automake-${AUTOMAKE_VERSION:=1.4}"
if automake=$(which "${scriptname}" 2>/dev/null)
then
exec "${automake}" "$@"
else
echo "$(basename $0): Error can't find '${scriptname}' in \$PATH." 2>&1
exit 1
fi
$
To get entirely sure that those wrappers are used, those scripts
could get a "magic" switch forcing them to say something like "I am the
GNOME automake wrapper". Together with few lines checking this string
added the configure scripts of some essential GNOME apps we would be sure
that really those wrappers are used...
Ciao,
Mathias
--
WWW: http://taschenorakel.de/mathias/
PGP/GnuPG: 1024-Bit DSA: ID 55E572F3, 1024-Bit RSA: ID EAAF7CF1
"e:-1" is the Slashdot Troll Emoticon. Often seen after the word "Scor"
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]