public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Marc Espie <espie@quatramaran.ens.fr>
Cc: gcc@gcc.gnu.org
Subject: Re: Get rid of libtool? [was Re: Makefile problems]
Date: Thu, 28 Feb 2002 00:49:00 -0000	[thread overview]
Message-ID: <orzo1u9gku.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: Marc Espie's message of "Thu, 28 Feb 2002 08:35:05 +0100"

On Feb 28, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote:

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

Certainly more.  It's a horrible mess.  I'm the first to admit it,
because I happen to know it pretty well.  I won't deny it.

What gets me annoyed is when people say `hey, let's throw all this
effort away and reinvent it poorly' or `hey, building shared libraries
properly is easy, why do I have to use this junk'.

Neither of these assertions are useful.  If people find libtool
unmaintainable, instead of criticizing it or threatening to replace
it, why don't they volunteer to re-do libtool in a more maintainable
way?  Then we'd have more people with a reasonable understanding of
this difficult business of abstracting away properties of static and
shared libraries.

But perhaps that's not what most people want.  Most people wish
creating libraries was trivial.  Well, with libtool, it is.  Without
it, you soon end up in a twisty maze of failures on all sorts of
different systems, or limit yourself to just a few OSs, for the
despair of users of the others.  And soon it is discovered that it
isn't that simple, and that there are serious problems with the simple
way of doing things, and then comes the choice of either living with
the problems or cluttering further the build system.

I agree libtool in its current implementation is not ideal.  But I'm
convinced its interface is very sane.  I'd love to have cooperation to
re-implement it properly, preferably from people interested in GCC
such that we wouldn't have to rely on me as a single point of failure.
But it's not going to be easy, just because building libraries
portably and managing their inter-dependencies is not easy.  I wish it
were, and I'd love to be proved wrong.  But I'm pretty sure I won't.

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

I disagree.  Its design is very good (thanks Gord!).  It's the
implementation that sucks.

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

Sure, let's go back to static libraries alone, then introduce shared
libstdc++ on a handful of platforms, then get to libjava and find out
that it's indeed not easy to get the multiple libraries it relies on
linked together properly.  But then it will be too late.

> I'm reasonably certain I'm alone in thinking like this. Do you want
> libtool to go on ? stop being blind to its issues.

I'm not being blind.  I do see what's going on, but there's little I
can do about it.  I can't do it all by myself, and those who are
interested in shared libraries don't appear to be interested in
helping get libtool re-implemented properly.  So what can I do? :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

  reply	other threads:[~2002-02-28  8:06 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
2002-02-28  0:49                   ` Alexandre Oliva [this message]
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=orzo1u9gku.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=espie@quatramaran.ens.fr \
    --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).