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

[Enrico Weigelt]

* Charles Wilson <cygwin at cwilson.fastmail.fm> schrieb:

> 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".  

Perhaps we've got some little misunderstanding. From what I've seen 
on a quick look, there're some changes which might be useful even if
the for some reason your current patch shall not be merged yet (i'm
not in the position to decide that), eg. cleaning up the cflags
handling a bit.

I, personally, try to make series of small changes instead of a 
single big one, to make collaboration easier (if just some of my
changes are merged, rebase will catch it ;-)).

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

Well, I didn't ask you to spend much time in reworking your whole
patch, just give some ideas ;-)

> 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?

hmm, it goes down to the question whether the env-passed CFLAGS should
be used exactly or if they should be added those internaly defined by 
the the package. IMHO the latte is the proper way.

> That's why automake has AM_CFLAGS and "regular" CFLAGS.  

Exactly that's why I'd propose: configure/makefile simply adds its
own flags to the existing $CFLAGS variable.

> zlib's build system doesn't have that flexibility; EXTRA_* implements it.

Your concept IMHO has the drawback that the caller always has to pass
these actual cflags. I'd prefer a configure script detecting the proper
cflags on the used toolchain instead of requiring me to do that manually 
(the latter would require me to implement special target-specific handling 
in my buildsystem, IOW: adding another layer - that's what I'd like to
circumvent, let the package do this on its own).
 
> > 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. 

Hmm, "defaults" is a wide range. As we're talking about target-specific
issues, there's no global default, but several per-target ones. And 
those should be detected/defined by ./configure, IMHO.

One thing I dont understand yet: why do you pass the mingw-specific
cflags/ldflags via $EXTRA_CFLAGS/$EXTRA_LDFLAGS instead of simply adding
them to $CFLAGS/$LDFLAGS in configure at the point where it detects mingw ? 
(well, I'm not a mingw expert, that would be your area ;-p)

> Setting a half-dozen configure arguments to separately set
> platform-specific CFLAGS values seems...overly complex.  

No, that's not what I want, but instead let configure find out the
stuff on its own. AFAIK that's exactly what autoconf does (or at 
least should do ;-)).


BTW: there's still a lot of things to clean up in the current 
configure script, eg. using uname is not optimal - instead we
should ask the toolchain for it's target (and only call uname
as last fallback) and operate on target-tuples only. But that's 
a different story.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt at metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------