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

Enrico Weigelt weigelt at metux.de
Fri Jul 23 13:35:39 EDT 2010


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

> > Well, libtool makes it even worse. It begins w/ a fundamentally
> > flawed design: rewriting command lines in a unpredictable and
> > undocumented way instead of providing an clearly specified own
> > interface. That's why I had to replace it by my unitool.
> 
> man, that's the best laugh ive had in a while.  let's take libtool 
> which has great portability across random/archaic systems, 

Yes, and totally breaking on crosscompiling (at least did it a 
few years ago). Beginning with such *insane* things like silently
adding certain _absolute_ pathes, adding _full_ pathes in the .la
output files when some tries to use sysroot, etc, etc, etc.

Yes, meanwhile they seem got it fixed somehow. But at the time
when I needed a clean crosscompile support, it was totally broken
and so extremly complex that a complete rewrite from scratch was
magnitutes faster than trying to understand thousands of quite
unreadable shell code and deeply nested macros producing shell code.
 
> rewrite it in java and 

Ah, and python is better ? ;-o

I wrote my buildsystem in java (actually that's just the reference
implementation, a proof-of-concept, and I choose java since I had
a lot of very useful tools/libs available right now - the underlying
concept is completely language agnostic), you (Gentoo) wrote yours
in python. I model features, you switch stuff a package migh use.
Whom of us now has the longer cock ?! 

OMGs!

> punt any semblance of portability in terms of output capabilities, 
> and then declare it better than libtool.

It's a totally different approach: model the functionality of toolchain 
components on an high level (eg. "please compile some source to an 
object" or "please link these objects together, importing these libs, 
some library or executable", but: "dont bother me with platform/toolchain 
specific stuff") instead of hooking up and rewrite gcc-alike commands 
(which btw changed notably in the years) and trying to get that running
on many different platforms. And one _major_ point is that all the
target/toolchain specific configuration is done at one single point:
the target config - NOT by each individual package for its own. So,
if you need some special adjustments, you have to do it only once,
instead of tweaking each single package.

Yes, I currently have just implemented an gcc backend, since that's 
my primary toolchain. But it's quite trivial to add other ones.


Oh, BTW: I started this thread to discuss an specific patch, which
only should add some more gnu-style commandline options to the 
current configure script (so eg. distro buildsystems which already 
understand the gnu-style don't need any futher adjustments for
zlib anymore ...), not to start an flamewar about make tools in
general ... could we perhaps get back to the original topic ? ;-o


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




More information about the Zlib-devel mailing list