Hi Reini, >>>>I'd rather run ./autogen.sh style scripts in the conf step. >> >> That would give the same patch size (usually it runs also aclocal, >> libtoolize, autoconf, automake).
> no, do it in the .sh script. That keeps the patch to the bare and > readable minimum, I cannot confirm that it reduces the patch sizes. It will always be huge, even if you use automake-1.8 where the upstream package includes automak-1.79 generated files. > and you only have to persuade the maintainers upstream to use > the newer 1.5 autotools. (just for our dll's, but what the heck.) > with the monster patch (new libtool, .in files, ...) they might get > frightened. I don't submit those patches upstream, the only patches I submit upstream are against Makefile.am and configure.in files and of course source fixes. > And our src dependencies in the README must list the -devel autotool 1.5 > requirements of course, otherwise it will fail, and your explicit patch > must be used. Yes, that is the reason why I include the patch, otherwise, Iwe could add lines like: /usr/autotool/devel/bin/autoreconf -fiv to the script, but then it will fail as soon as newer autotool version are avaiable or the user has older versions installed. Additionally I need to use a pacthed libtool which is also included with the patch, if I would not patch libtool I would have to patch at least ten Makefile.am of GLib & Co. and probably other packages too. Gerrit -- =^..^=
