Re: [patch] fix parallel build failures in xfsprogs-3.0.0

From: Andreas Gruenbacher <agruen@suse.de>
To: Greg Banks <gnb@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Eric Sandeen <sandeen@sandeen.net>,
	Mike Frysinger <vapier@gentoo.org>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0
Date: Fri, 27 Feb 2009 10:55:51 +0100	[thread overview]
Message-ID: <200902271055.51564.agruen@suse.de> (raw)
In-Reply-To: <49A794D3.2000904@sgi.com>

On Friday, 27 February 2009 8:22:59 Greg Banks wrote:
> Andreas Gruenbacher wrote:
> > On Thursday, 26 February 2009 16:17:28 Mike Frysinger wrote:
> >> yes.  i dont know why the xfs progs have been packaging these
> >> autogenerated files by themselves.
> >>
> >> - remove aclocal.m4 from git
> >> - run `aclocal -I m4`
> >> - run `libtoolize -c -f`
> >> - run `autoconf`
>
> Some packages provide a shell script called autogen.sh which automates
> all those tedious autotools steps.  The Gnome autogen.sh is fairly
> general and does things like check for autotools versions and work out
> dynamically which tools to run.
>
> http://svn.gnome.org/viewvc/gnome-common/trunk/autogen.sh?revision=3902&vie
>w=markup
> http://svn.gnome.org/viewvc/gnome-common/trunk/macros2/gnome-autogen.sh?rev
>ision=3913&view=markup
>
> You don't need all that of course, you could get away with a 5-line
> shell script.  As long as you call it "autogen.sh" people should know
> what to do.
>
> > You mean this should become the normal build process?
> >
> > I was actually more thinking along the lines of reducing build
> > dependencies by adding a few more generated files like ./configure ...
>
> Not in a version control system.  Otherwise developers who do run
> autoconf, using a different version of autoconf from you, will get an
> enormous spurious diff in the configure script which they have to decide
> whether to ignore or not.

Of course, the classic way is to keep all the generated files out of the 
repository. On the other hand, if we added all the generated files to the 
repository, all that would be needed would be creating a new release would be 
creating a tag and making a tarball. Have a look at cgit: if configured that 
way, the web interface offers to download any tagged version as a tarball. 
Those tarballs are generated on the fly (e.g., 
http://git.savannah.gnu.org/cgit/).

Jumping between different versions of the auto* tools would become quite ugly, 
and we would have to avoid jumping between versions. So maybe that's more 
trouble than it would be worth.

Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs