[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libjava build times]

From: Bob Friesenhahn
Subject: Re: [libjava build times]
Date: Tue, 10 May 2005 09:45:20 -0500 (CDT)

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 Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]