espie:
[...] 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.
aoliva:
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'.
I've been reviewing libtool recently and hope to have a more complete
response to it later, but just on a preliminary basis -- I think a lot
can be done to drastically improve libtool without throwing away all
the effort that's gone into it so far.
Among my major sources of praise is the presense of all those testing
tools. Those make it far more tractable to improve the implementation.
Among my major complaints so far are:
- the way that ports happen / the way that platform details
are represented
- the reliance on autoconf
- the absense of comments
- the absense of technical documentation
- the monolithic implementation
I think the information that goes into a port can be profitably
factored out, most of it into a plain text, commented database, with
perhaps a little bit of per-platform scripting. The result would be a
database, mostly independent of the rest of libtool, describing the
mechanics of libraries on all supported platforms/compilers. Through
cleverness, I'm hoping that such a database can be produced mostly
automatically using the existing libtool implementation itself.
The reliance on autoconf and m4 and a number of idioms inherited from
autoconf for writing portable shell code is, I think, a lot of the
source of the perception that it's hard to maintain. I understand
that that reliance is a conservative choice if you're just down the
hall from some of the "auto*" maintainers -- based on the fact that
autoconf encapsulates a lot of accumulated wisdom and tricks for
writing portable scripts -- but I think there are far more
maintainable approaches.
Another part of the maintainability problem is the absense of good
comments and documentation. The user manual describes the abstraction
that libtool tries to maintain, but would be usefully accompanied by a
review of libraries in general, describing the kinds of variations
seen, and sections for each platform/compiler/configuration locating
that system in the space of library-handling variations. The internal
abstractions used by libtool are barely documented at all in comments
-- it's in a horrible state in that regard.
The fact that all that functionality is lumped into one huge script
makes the code ridiculously hard to read and the internal abstractions
ridiculously hard to identify. Making those abstractions more
explicit by breaking up the huge script into functions and/or
subscripts with documented interfaces would help a lot.
The comment in the user's manual that if you aren't using automake
you're "on your own" is a bad sign for the abstractions that libtool
wants to give users, to put it mildly. Even if I wanted to use
automake I'd find that flippant remark to be an off-putting,
red-flag-raising clue. Getting those abstractions to the point where
they are easy to use independently of the "auto*" tools is important
-- I don't see how you can claim to have a well designed tool
otherwise.
(I haven't yet gotten far into reviewing "libltdl".)
-t
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
