[Zlib-devel] [Patch] support for building DLL for cygwin, mingw

[Charles Wilson]

On 8/4/2010 1:57 PM, Enrico Weigelt wrote:
> * Charles Wilson schrieb:
> 
>>> I'd prefer if's instead of putting commands into variables ;-p
>>
>> It's a smaller change to do it this way; I was trying to keep the
>> magnitude of the changes smaller, for easier review.  Certainly tweaks
>> along those lines can and should be discussed...
> 
> hmm, perhaps it'd be advisable to make the changes in smaller
> steps and contigiously rebase to recent upstream releases.

Well, zlib's build procedure either DOES or DOES NOT have the ability to
compile a shared library on cygwin/mingw -- there's no "halfway".  I've
been in the "DOES" camp for almost 10 years; if I broke up an existing,
working patch and submitted only the first part with no context...it
would most likely be ignored as a useless bit of drivel. Because that's
what it would be.

Now that the list sees the whole thing, then maybe splitting it up into
pieces makes sense.

However, no offense to you, Enrico, but I need to lurk for a while to
learn how this list operates, before jumping to implement the
recommendations of the first person who happens to respond.  So I won't
be updating anything right away...

>>> Why not simply passing them via common CFLAGS/LDFLAGS variables on
>>> ./configure call ?
>>
>> Because (a) zlib's configure doesn't appear to have a concept of
>> precious variables, unlike autoconf-generated configure scripts, and (b)
>> setting them that way appears to *override* the ones established by the
>> configure script, rather than allowing you to append "extra" settings on
>> top of the automatically determined ones.
> 
> hmm, fix that ? ;-)

Is that a BUG or a FEATURE?  If I *set* CFLAGS, how do you know I'm not
saying "yes, I know what the configure script wants to do, but I have
special requirements and know better.  Use **this** instead."?   Ditto
LDFLAGS?

That's why automake has AM_CFLAGS and "regular" CFLAGS.  zlib's build
system doesn't have that flexibility; EXTRA_* implements it.

>>>> The reason EXTRA_* flags are used for mingw, instead of hardcoding them
>>>> in configure, is because these options change the library's ABI, and
>>>> this is the way the mingw and cygwin projects will be building them.
>>>
>>> Maybe it would make sense to add own ./configure options for this ?
>>
>> Well, I wasn't sure how many additional system-specific options would be
>> welcomed.  Right now, configure is rather svelte -- do we really want to
>> bloat it with a bunch of platform-specific "--use-ms-compatible-structs"
>> options and the like?
> 
> IMHO thats way better having them in one place than passing dozens
> of cflags to make. My ideology is that ./configure $options && make 
> && make install should be sufficient.

Well, it IS sufficient, if you want the defaults.  What we're arguing
about is how best to affect the build when you DON'T want the defaults.
Setting a half-dozen configure arguments to separately set
platform-specific CFLAGS values seems...overly complex.  All that
hand-written parsing and shell code to deal with dozens of new configure
options, is bound to be brittle and crufty...vs. "to add to the default
CFLAGS, set the EXTRA_CFLAGS variable before calling make".

(there's a second argument about whether my demonstrated "recipes"
should instead be enshrined AS the defaults.  I didn't quite have enough
hubris to propose that)

--
Chuck