Re: [libjava build times]

[Ralf Wildenhues]

[ BTW, I have removed the email address from Subject.  When I started to
use email, it was considered bad style to put names or addresses in
subjects, but that might've changed;  I've not noticed until now, sorry. ]

Hi Bob,

* Bob Friesenhahn wrote on Fri, May 06, 2005 at 05:31:32PM CEST:
> On Thu, 5 May 2005, Ralf Wildenhues wrote:
> >
> >>Libtool has been around since 1996 but its implementation is still
> >>fundamentally broken.
> >
> >Which part is _fundamentally_ broken?  Being a shell script it can be
> >slow, yes, and quoting is a pain, but you get that with `make',
> >`autoconf' or `automake' as well, in slightly different settings.
> 
> I did not mean to offend ... by "fundamentally broken" I mean that it 
> is impossible for a shell script to reach the performance levels of 
> compiled code.

ACK.  This is a trivial statement, though.

> There is a philosophical issue which is currently forcing libtool into
> this model.

Historical practice would be more to the point, I believe.  And: "lots
of projects currently use it that way."

> Libtool is doing things that it doesn't need to do.  There are
> perceived "requirements" which are not actual requirements.

Which ones?  Please make a list.  This is an honest question -- I can
think of what you mean, but do not wish to speculate.

> Interposing libtool beween 'make' and the compiler/linker shouldn't 
> consume more than 1% of the time or so.  On some systems (e.g. 
> Microsoft Windows) it seems to consume 80-90% of the build time.

1% is really tough.  It's also not well specified, because most tools
need at least some constant overhead, which will be large if your
project is small.  OTOH, you should not create lots of tiny shared libs
anyways, and unless you develop a compiler or a libc, you should not
create libs with one object per exported symbol either.  Basically I
consider it ok to assume that people read Drepper's dsohowto (even if
some comments therein about Libtool are outdated. :)

For sane projects, I am pretty convinced that I can get libtool overhead
to about 10%, by using a simple libtool-cache like mechanism for compile
mode (for link mode see [1] or write a bug report if you have a
different test case).  But then again, all that probably won't help if
all you are compiling is one ten-line C translation unit without
optimization. 

(BTW, my idea is to have a compiled, pre-installed lt-cache binary which
itself does not care about the configuration currently compiled.  Not
sure yet if the idea carries all the way through, though.)

> >I get your repeated point about ltmain.c.  But let me tell you
*snip*
> I didn't claim it was easy, however, a thousand mile journey starts 
> with a single step.  At the moment, there is not even the start of a 
> plan.

I would love to hear what you really aim at.  Because this:

> By making the libtool binary a tool that you install in advance 
> (similar to 'make') a huge amount of the effort can be relieved. 
> Each package would then only need to provide a small bit of 
> configuration information.  Each package would configure and build 
> much faster.  Some small packages would be much smaller due to 
> elimination of most of the configure script.  It is not uncommon for 
> most of the configure script run time to be consumed with 
> libtool-related processing.

sounds like you'd like to replace both Autoconf and Libtool with an
`imake'-like approach.

> We already assume that the user has been able to procure/install make, 
> a C compiler, and many other tools.  It doesn't seem like a big deal 
> for packages to require that libtool be installed.

So you would like to kill _all_ libtool-related `configure' tests and
replace them with lookup tables, too?  Or have one installed `libtool'
per compiler, compiler flags, linker, ..?

The first is bound to be a _huge_ amount of work, and IMVHO, like imake,
fail.  BTW, right now we assume a more-or-less POSIXy system.   And
implement workarounds so stuff like MinGW works as well.

Regards, and no offense intended either,
Ralf

[1] http://lists.gnu.org/archive/html/libtool-patches/2005-05/msg00076.html