From: Marc Espie <espie@quatramaran.ens.fr>
To: aoliva@redhat.com
Cc: gcc@gcc.gnu.org
Subject: Re: Get rid of libtool? [was Re: Makefile problems]
Date: Thu, 28 Feb 2002 00:02:00 -0000 [thread overview]
Message-ID: <200202280735.g1S7Z5809069@quatramaran.ens.fr> (raw)
In-Reply-To: <orzo1ucqjn.fsf@free.redhat.lsd.ic.unicamp.br>
In article <orzo1ucqjn.fsf@free.redhat.lsd.ic.unicamp.br> you write:
>On Feb 25, 2002, Richard Henderson <rth@redhat.com> wrote:
>> How many people can fix problems with libtool when they occur?
>Err... Zero? :-)
>Oh, you meant after they occur. Perhaps half a person :-)
>> How many people can fix problems with make when they occur?
>Other than the maintainers of make?
Maintainers, plural. Several makes, lots of maintainers.
I've seen people here in the past who can fix bugs in make that
don't seem to be make maintainers anyways.
As a guy who does both, I'm only tweaking libtool VERY reluctantly.
This thing is at least one harder of magnitude LESS maintainable than
a Makefile, and probably more. This partly comes from the fact that it
is impossible to debug shell scripts of such a size. This also comes from
the fact that libtool is incredibly bloated, and does really, really need
a complete redesign.
The redesign will only happen if someone who cares about it does it.
All that people like me will do is say `we shun libtool because it's
incredibly bloated and badly need a redesign, and our life is currently
much easier without it anyways'.
Out of the auto-suite, I can live with automake and its quirks, I can
live with autoconf and its quirks, heck, I can live with cygnus-configure
and its quirks... and I could very well live without libtool.
Okay, this looks like highly flammable material, but think about it.
I'm reasonably certain I'm alone in thinking like this. Do you want
libtool to go on ? stop being blind to its issues.
next prev parent reply other threads:[~2002-02-28 7:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3C78B3B6.5000303@waitaki.otago.ac.nz>
[not found] ` <87it8mbse7.fsf@tf1.tapsellferrier.co.uk>
2002-02-24 16:21 ` Bryce McKinlay
2002-02-24 19:16 ` Brian Jones
2002-02-24 19:35 ` Phil Edwards
2002-02-24 19:45 ` Alexandre Oliva
2002-02-24 19:59 ` Bryce McKinlay
2002-02-24 21:22 ` Alexandre Oliva
2002-02-24 22:05 ` Jeff Sturm
2002-02-24 22:17 ` Phil Edwards
2002-02-24 22:24 ` Alexandre Oliva
2002-02-24 23:20 ` Phil Edwards
2002-02-25 5:36 ` Alexandre Oliva
2002-02-25 9:10 ` Alexandre Oliva
2002-02-26 18:41 ` Jeff Sturm
2002-02-26 18:47 ` Richard Henderson
[not found] ` <3C7C4E67.6050001@waitaki.otago.ac.nz>
2002-02-27 2:41 ` Richard Henderson
2002-02-27 17:55 ` Alexandre Oliva
2002-02-25 16:56 ` Richard Henderson
2002-02-25 17:00 ` Richard Henderson
2002-02-27 18:06 ` Alexandre Oliva
2002-02-27 20:17 ` Albert Chin
2002-02-28 0:02 ` Marc Espie [this message]
2002-02-28 0:49 ` Alexandre Oliva
2002-02-28 17:35 ` Phil Edwards
2002-07-03 15:41 Nathanael Nerode
2002-12-28 5:08 ` Alexandre Oliva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200202280735.g1S7Z5809069@quatramaran.ens.fr \
--to=espie@quatramaran.ens.fr \
--cc=aoliva@redhat.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).