[Top] [All Lists]

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

To: Andreas Gruenbacher <agruen@xxxxxxx>
Subject: Re: [patch] fix parallel build failures in xfsprogs-3.0.0
From: Greg Banks <gnb@xxxxxxx>
Date: Sun, 01 Mar 2009 12:31:01 +1100
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, Mike Frysinger <vapier@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <200902271055.51564.agruen@xxxxxxx>
Organization: File Serving Technologies ; Silicon Graphics Inc.
References: <200902240010.25434.vapier@xxxxxxxxxx> <200902261817.02604.agruen@xxxxxxx> <49A794D3.2000904@xxxxxxx> <200902271055.51564.agruen@xxxxxxx>
User-agent: Thunderbird (X11/20060911)
Andreas Gruenbacher wrote:
> 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. 
If the point here is to reduce the workload and potential errors
involved in making a release, you could add a release: target to the
Makefile to do the release procedure.  That target only needs to work
for the maintainer, so it's relatively easy.  You could do the stored
version bump, the tagging, the autotools futzing, and release tarball
building in there.

> 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/).
Oh, now I see where the idea of checking in generated files comes from :-)
> Jumping between different versions of the auto* tools would become quite 
> ugly, 
Absolutely, you want to avoid that.  But conversely you can't rely on
everybody who ever needs to change configure.ac having exactly the same
version of autoconf as the maintainer.

Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.

<Prev in Thread] Current Thread [Next in Thread>