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

[Enrico Weigelt]

* Volker Grabsch <vog at notjusthosting.com> schrieb:

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

yes, I've also fixed that in my oss-qm branch.

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

git-rebase will hopefully catch it ;-p
(it's still ugly that my upstream changesets have the granularity
of release tarballs :()

> > Interesting. How do you handling crap like AC_TRY_RUN or AC_CHECK_FILE ?
> 
> Replacing it with a more suitable construct.

Well, you'll first have to find and then replace them all.
And to be sure, you check each upcoming release again and again :(
 
> Fortunately, most packages don't use that non-cross stuff
> anyway, so that isn't a big issue.

Some packages just introduced it lately ...
 
> 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.

NAK, can't confirm this. Most cases I've seen are quite trivial
things, like finding out typesizes or checking if some ancient
version of an important library has some strange bug ... ;-o

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

Depends on the individual package.

> Also, Autoconf appears to be fairly backwards compatible since 2.59.

There have been major breaks between 2.59 and 2.60 (that's the reason
why mozilla's still stuck in ancient 2.59 - they've refused my patches
for upgrading to newer autoconf, years ago).

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

No, I'm talking about things that happen on daily basis. Little typos
(eg. some missing semicolon) in macros can produce ugly bugs that only
pop up in specific situations. That's because the m4/autoconf language
has no stricly enclosed syntactical structures. And then you've got
a hell of trouble finding the actual root cause. It's a design problem.

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

config.log only tells you the line of the generated shell code, where
the error happened, but no reliable indication of the root cause.
and _that_ is what makes the big trouble.

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

Well, I've did some (yet unclean ;-p) experiments for zlib in this
area (see the hacking branch @ git://pubgit.metux.de/oss-qm/zlib).

It tourned out to be quite easy to do that in a generic way, so
that most of the stuff can be shared with other packages.

I'd propose the follwing steps:

#1: find out the toolchain commands (IOW: if not passed via env,
    set default values)

#2: test the toolchain commands and check which type they're
    (eg. gcc, tcc or certain proprietary ones). this process
    might also set certain variables or create wrapper commands
    for certain highlevel operations (eg. "compile a source to 
    an object", "link several objects to an library", etc).

#3: ask the toolchain for what target it is building for (no, do
    _NOT_ decide on uname directly) and maybe add target-speficic
    variables (define's, pathes, command flags, etc)

#4: create an config.mk file, which is included by the actual
    Makefile's

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

Dependencies should not be the problem. They'd have to be fetched via
pkg-config. If some dependency doesnt provide one yet (only a few),
run an additional test scipt (which goes away since the package in
question provides a .pc file).

BTW: very much of the stuff autoconf is doing (or has been done in
history) comes due the lack of an tool like pkg-config. At the point
where packages begin to write .m4 macros for importing their packages,
they instead should have provided more generic ways (like writing
something like pkg-config).


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