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

[Enrico Weigelt]

* Mike Frysinger <vapier at gentoo.org> schrieb:

> your comparison makes absolutely no sense.  Gentoo's python usage 
> is in a package management tool and is not redistributed with 
> random upstream packages. 

Same applies to unitool. It's just a command line tool for calling
the actual toolchain commands in a platform-agnostic way and exists
as an separate package, just like make, cmake, etc, etc.

> libtool is pure generated shell code and redistributed with 
> packages that use it.  

That misdesign is libtool's fault. Unitool is _NOT_ bundled into
any other package. And it also does _NOT_ put any autogenerated 
scripts there. It is simply called by the makefiles (or whatever
you use)

> if unitool is intended as a libtool replacement, then you should 
> be comparing it to libtool.

No, it isn't. It just happens to provide an drop-in replacement
for libtool (just replace libtool.sh by an one-liner which calls
unitool-lt instead). Unitool had been developed earlier for other
purposes, the libtool replacement came later (ontop of unitool).

> > It's a totally different approach
> 
> which completely ignores the entire point of libtool. 

Absolutely not. It considers the libtool concepts very well, in a
way of _not_ doing such silly designs anymore.

> it works everywhere. unitool works in very few places.

Well, (g)make also runs "everywhere". why ? because it had been 
ported (and built onto that platforms), also gcc, glibc, etc, etc.

And the same can be easily done w/ unitool: simply add another 
backend for the new toolchain types or profiles for your target.

The major point of unitool is to put this all into one central
place and let the individual packages just call an platform 
agnostic interface instead of trying to do that all on their own.
This makes special target specific adjustments *much* easier w/o
even touching the individual package (eg. when you want to have
certain libs statically linked or control which versions to use,
the package itself doesnt ever have to know about that - it's 
all hidden behind the interface).


Okay, can we now get back to the original patch ?


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