[Zlib-devel] [PATCH] configure: now accepting all gnu-style path options

[Volker Grabsch]

Enrico Weigelt <weigelt at metux.de> schrieb:
> * Volker Grabsch <vog at notjusthosting.com> schrieb:
> 
> > As the maintainer von Mingw-cross-env I can confirm this. We have
> > the special "strangeness" of not only cross-compiling but also
> > static linking.
> > 
> > Many packages need some tweaks, and Zlib is no exception to this.
> 
> Why does --static not work ?

Our current patch is:

____________________________________________________________________________

[Makefile.in]
-       cp $(STATICLIB) $(DESTDIR)$(libdir)
-       cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)
+       [ -z '$(STATICLIB)'  ] || cp $(STATICLIB)  $(DESTDIR)$(libdir)
+       [ -z '$(SHAREDLIBV)' ] || cp $(SHAREDLIBV) $(DESTDIR)$(sharedlibdir)

[configure]
-# temporary bypass
         rm -f $test.[co] $test $test$shared_ext
-        echo "Please use win32/Makefile.gcc instead."
-        exit 1
____________________________________________________________________________


Note that this patch is used for the Zlib-1.2.5 release. The issue seems
to be solved the current Zlib dev version, so we hope to be able to remove
that patch when Zlib-1.2.6 is released.


> > The packages which use Autoconf usually make the _least_ trouble.
> 
> Interesting. How do you handling crap like AC_TRY_RUN or AC_CHECK_FILE ?

Replacing it with a more suitable construct.

Fortunately, most packages don't use that non-cross stuff
anyway, so that isn't a big issue.

Those rare packages that really to those macros usually have
a deeper issue (e.g. sharing code & libs with their code
generators, etc), so they need a complete redesign of their
build system anyway. That is, they wouldn't be any better
if they hadn't used Autoconf.

> > And trouble is usually the result of maintainers writing some short-
> > sighted shell code directly into their configure.ac, instead of
> > calling the appropriate macros.
> 
> True. 
> But looking at the heavy (often badly-documented) syntactic and 
> semantic changes between different autoconf release, I can really
> understand why people prefer to write their own code.

However, that code is often worse than what it tries to replace.
Also, Autoconf appears to be fairly backwards compatible since 2.59.
Are you sure you didn't confuse Autoconf with Automake? ;-)

> Autoconf is far from being syntactically stable: a small typo can
> result in unpredictable problems which might only pop up in certain
> situations.

I didn't encounter such problems yet, at least not with static
cross-compiling for win32. Are you sure you aren't talking
about some obscure bug that has been fixed in Autoconf long ago?

> And the superfat generated configure scripts are quite
> undebuggable. That's due it's nature of being an m4-based language.

With the help of config.log I was often able to debug them without
too much hassle. Although Autoconf is far from perfect in that
regard, it is more friendly than e.g. CMake and many other build
systems I've had contact with.

> Actually, I don't see why a similar functionality couldn't be 
> provided by a bunch of generic shell functions.

I don't know, because I haven't tried yet, and because I don't
have contact with too many exotic operation systems (apart from
MacOS X, Windows, OpenSolaris and SuSE Linux ;-)).

However, I do know that quite a lot of people try to do so, and
fail regularily. Zlib is one of the rare exceptions, but it is
also a quite simple package - a single library with extremely
few dependencies.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR