Re: [libjava build times]

[Bob Friesenhahn]

On Tue, 10 May 2005, Ralf Wildenhues wrote:
> > 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.

But true!

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

First and foremost is that every project needs to be self-sufficient 
and should only need a legacy Bourne shell, legacy make, and a 
compiler.  By providing an easy to install libtool package which does 
not automatically overwrite m4 macros used by an existing autotool 
install, then libtool can simply be made as pre-requisite just as some 
projects require `jam', `ant', `qmake', or some other build tool.  If 
this is a an official GNU direction, then the per-project bloat caused 
by libtool can be eliminated in favor of configuring and installing 
libtool just one time.

I understand that local build tool may change, or supplied options may 
alter behavior, so each package would still need to include some 
libtool-related configuration.  The configure script would generate a 
configuration file which is read by the installed libtool at run-time.

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

No, there would still be some tool/option related configuration.

> 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

It is worth noting that imake failed because it was designed for OS 
vendors rather than end users.  Imake is very rigid and it can be 
challenging to properly alter its behavior.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/