This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] libgcrypt-1.2.0-2


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
-- 
=^..^=


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]