[Zlib-devel] zlib 1.2.3.6 available for testing

[Enrico Weigelt]

Vincent Torri wrote:

>> How do you know which OS'es are still used out there ?
> 
> from friends, in their personal uses and in their work (lots are
> involved in computer jobs). Do you really think that supporting ms dos
> OS is useful ?

Well, from a personal business viewpoint I would have to say
"please drop support immediately", so I can sell it for big
money ;-)

>>> Autotools are a framework used mostly to create Makefiles (they may have
>>> other uses than creating Makefile's though).
>>
>> Yeah, it's a fine tool to make your code ugly and broken.
> 
> because you don't know how to use it correctly.

An very interesting point: you'll first have to spend several weeks
in full-time to learn how to use it w/o shooting yourself. Of course
that's much better than writing a makefile in a few mins.

Again, from a business viewpoint (assuming you can charge your
customer for all the time spent), thats a good way ... ;-o

>> I'm just got too lazy for counting the autoconf hassle I had in
>> recent years, especially when it comes to things like crosscompiling.
> 
> i'm cross compiling easily with them since years

Maybe you just happend to have to somebody else doing the dirty
for you (maybe some of the patch repositories out there) ;-p
If you're doing all cleanly from scratch (w/o extra crosscompile-
hacks, etc), you'll soon run into trouble (yes, it got much better
in recent years) ... just starting w/ lots of totally incompatible
autotools versions, classics like AC_TRY_RUN, AC_CHECK_FILE, etc ...

A few years ago I had to write my own libtool replacement, since
that thing was totally incapable of handling sysroot builds and
fixing that spaghetti pot would have been far to complicated.

> if the configure script supports that... I've seen lots of configure
> scripts that are badly written, lots that are quite well written. 

Yes. Bad ones are eg. openssl or perl (yes, perl requires itself
for building, what a fun ;-o).

> Each time, it is a pain to support multiple OS with a hand written
> configure.

Right. But that could also be done easily by a set of well-structured
shellscripts (a bunch of includes provided by some separate package).

> You spend more time to write a good configure script than using the
> autotools (if you know the autotools, of course).

Assuming, you're an autoconf expert and *really* know what's going
on under the hood.

>>> You just have to correctly write the configure.ac file.
>>
>> Yeah, that's the real challenge.
> 
> I agree. autotools are a real pain for developpers, but very handy for
> users.

Here at this list, we're developers. I'll assume we all know what
we're doing quite well. Our job here is to provide a technically
good package which is easy to build/install. IMHO, it's hard to find
packages which are much more convenient to build/install than zlib
(even mature gnu.org packages like ncurses can be *much* harder
to build cleanly - just have a look at my branches in oss-qm repo).

You find autoconf's ./configure scripts convenient to use ?
Well, me too (at least if they're not broken) - that's why I patched
zlib's configure to accept all autoconf-style path arguments
for convenience, years ago. But we still should differenciate
between the interface and the actual code behind.

>> For such a small and mature package like zlib I don't really
>> see the need for such a major change.
> 
> haha, funny that you take one of my arguments when I talk about svn vs
> git :p

That's a very different issue. At this point we were talking about
choosing an vcs for tracking changes, not about doing big changes
in mature files.

> yes, it is small. And it's not necesary to use the autotools. The
> current system is working. But a change in the files (change of names,
> adding or removing files, options passed to the proprocessor, compiler,
> linker, etc...) mean a change in more than 10 Makefiles, that is, a high
> probability to make mistakes when updating them.

True. But we could easily move common parts to includes or
splitted templates for auto-generation - step by step. And so
we can write code that can be easily understood by people who
are not autoconf experts.


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

 cellphone: +49 174 7066481   email: info at metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------