Re: GNOME 2.2 screenshots

[James Henstridge <james daa com au>]

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.
>  
I have been building the core gnome 2.0 modules with automake 1.6 for 
quite a while.  I had to make adjustments to a number of modules in 
order to get them to build correctly.  These changes were often real 
bugs.  One example was bad use of AM_CONDITIONAL.  Some configure.in's 
had the following in them:
   if test1; then
       ...
       AM_CONDITIONAL(FOO, test2)
       ...
   fi

With automake 1.6, this raises an error, but doesn't with 1.4.  It is a 
real error with both automakes, as if test1 is false, then neither 
FOO_TRUE and FOO_FALSE get defined to '#', so both the true and false 
paths in the Makefiles get activated (which could give unpredictable 
results).

There were a number of other issues like this that were bugs that only 
got reported in 1.6.  Given that most of the core modules can already be 
built out of CVS with 1.6 (not necessarily make distcheck'd), I think 
you are overstating the problems.

James.

--
Email: james daa com au              | Linux.conf.au 2003 Call for Papers out
WWW:   http://www.daa.com.au/~james/ |   http://conf.linux.org.au/cfp.html