Status of libtool 2.2.X?

[Till Maas]

On Sat October 11 2008, Kevin Kofler wrote:
> Till Maas <opensource <at> till.name> writes:
> > Afaik, it is best practices to create a patch for upstream agains
> > configure.ac, then run autoreconf etc. locally and then create a diff
> > between the upstream tarball and the new contents and use this in the
> > spec file, which would be a patch agains configure. Then you do not need
> > to run autoreconf in rpmbuild.
>
> But unless you manage to find the exact same versions of the autotools
> upstream used (which are in general not packaged for Fedora at all), the
> patch will be huge and contain lots of bogus changes due to the autotools
> version change. For example, autoconf often adds support for some exotic
> target or a workaround for some obscure shell's bug from one minor version
> to the next and that support code or workaround gets copied up to dozens of
> times into the generated configure script. Also things like copyright dates
> and revision numbers appear at many places. So a diff for the generated
> files can be huge even with _no_ change to the sources, and the actual
> change will be hidden in the mess. Patches of that kind also have to be
> regenerated at every single new upstream version.
>
> In most cases, patching generated files is a bad idea.

I do not understand, why the huge changes are a big problem. The massive 
amount of changes is how autotools work. The "hidden change" can imho be 
better seen in the patch to the autotools input files, which still exists. 
Also in case upstream is not dead and is still providing new versions, the 
upstreamed patch should be in the next released version, so you do not have 
to regenerate the patch.

In case there is a demand to recreate the patch often, we could add a helper 
target (prepare-patch) to Makefile.common that does:

find -type f \! -regex ".*\\.configure.in$" -exec bash -c 'test -f 
{}.configure.in || cp -a {} {}.configure.in' \;

For the case the patch is called foo-1.2.3-configure.in.patch
Then you can run

make prep prepare-patch SUFFIX=configure.in
cd foo-1.2.3 && autoreconf
make patch SUFFIX=configure.in

To update the patch. To get rid of the bogus diff lines from the patch, you 
can add another
make prep patch SUFFIX=configure.in
after this.

If you want to keep some head in the patch, you can also use rediff instead of 
patch btw.

To make it even more easier, we could add a target, that does all the above 
and asumes that there is a script in the branch dir, that is called 
autogen.sh and does all the stuff that is used to run autoreconf and the 
patch should use the suffix autogen-patch, so you only need to run

make autogen-patch or all is done automagically.

Thinking of it, I will add the prepare-patch at least to my .cvspksrc, because 
it makes running make patch a lot simplier.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081011/0938997f/attachment.sig>