[Bug 226671] Merge Review: zlib

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=226671





--- Comment #34 from Stepan Kasal <skasal at redhat.com>  2009-01-07 07:58:20 EDT ---
(In reply to comment #31)
> Really the only thing that bothers me is [...] the autool-ization of the
> original non-autotools-using source.

First, about problems with the original build system of zlib:
The same CFLAGS variable is used for static and dynamic library. So using this
simple build system is not so simple as using the complex autotools system.
You need to do something like:
make
mv libz.a save-libz.a
make clean
./configure -s
make
mv save-libz.a libz.a

To see another variant of this trick, see the spec file just before the
autoconfiscation:
http://cvs.fedora.redhat.com/viewvc/devel/zlib/zlib.spec?revision=zlib-1_2_3-6_fc7

Second, there is minizip-*-autotools.patch.
contrib/minizip/Makefile does not contain any rules for building libminizip.so.
Consequently, some hacking is needed to get the library built; using libtool
(through Automake) is a sensible way.

With these things in mind, I believe that the autoconfiscation incures less
maintanance costs than the complicated spec file would.

Does this sound fair?
If yes, should an excerpt of this explanation go to the spec file?
(Text suggestions welcome. ;-)

BTW, I'm going to do some cleanup of the autotools patches.  But I don't think
it would be a good idea to go back to the build system shipped with zlib.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.