[Top][All Lists]

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

Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with ha

From: Alexandre Oliva
Subject: Re: [MAD SCIENCE EXPERIMENT]: Replace some libtool functionality with handcoded C
Date: 04 Dec 2003 04:44:00 -0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

On Dec  3, 2003, Mohan Embar <address@hidden> wrote:

> I wanted to see how much faster the libgcj build would go if I took
> libtool out of the picture for some of the pieces.

I'm not all that surprised your C program is much faster that the
shell script.  For starters, it fails to support all of libtool's
configure-time options, such as --disable-static, --disable-shared,
--with-pic, as well as their per-compilation equivalent command-line

That said, even if it supported them all, I do believe there's a lot
of potential for such code.  It has been in libtool's roadmap since
long before I pretty much stopped working on libtool, which was a
while before release 1.5.  There were a number of discussions about
doing in C what we currently do in a slow and unmaintainable shell
script.  Gary V. Vaughan had a small language with a small interpreter
that could reasonably be bundled into a libtool package as a
replacement for ltconfig/, but we never got as far as
integrating it an actually making the transition.  I suppose if you'd
like to do that, it would be very welcome, since many people
(rightfully) complain about libtool slowing things down, and using a
fast shell with many built ins isn't quite enough to get builds fast.

Back during the GCC summit, Zack Weinberg suggested an alternative
approach that could speed things up: getting the libtool code to
define additional Makefile macros that would enable someone to inline
the libtool calls into the Makefile itself.  We talked a lot about it,
and it seems to me that if we got libtool to define the macros
referenced below and automake to generate them, we could have some
significant speed up by avoiding the need for the shell to at least
parse the entire libtool script for every command.  That said, we
might be able to achieve similarly good results by simply splitting
the several libtool --modes into separate files, that could then be
ran with `.', which would at least minimize parsing.

foo.lo: foo.c
        lofile=$@ dir=. ofile=foo.o; \

given the following possible additional definitions: (yeah, it's ugly,
and I sort of doubt we can get AC_SUBST to portably emit
LIBTOOL_END_COMPILE_CC like the snippet below, but hey!, it *might*
work, even if we have to break it up in smaller pieces to avoid
running into hard-coded limitations of sed substitutions)


  { test -d $$dir"/$(libtool_libdir) || \
    $(mkdir_p) "$$dir"/$(libtool_libdir); } && \
  rm -f "$$lofile"T "$$lofile" "$$dir/$$ofile" \
    "$$dir/$(libtool_libdir)/$$ofile" || : ; \
  $(LIBTOOL_COMPILE_CC_PIC) -o "$$dir/$(libtool_libdir)/$$ofile" \
    $${1+"$$@"} && \
  $(LIBTOOL_COMPILE_CC_NONPIC) -o "$$dir/$$ofile" $${1+"$$@"} && \
  { echo pic_object=$(LIBTOOL_PIC_OBJECT); \
    echo non_pic_object=$(LIBTOOL_NONPIC_OBJECT); } > "$$lofile"T && \
  mv "$$lofile"T "$$lofile"

mkdir_p = mkdir -p # or $(mkinstalldirs), depending on configure tests

libtool_libdir = .libs # or _libs, depending on configure tests

LIBTOOL_COMPILE_CC_PIC = $(CC) -fPIC -DPIC # or equivalent, or :
LIBTOOL_COMPILE_CC_NONPIC = $(CC) # or : if disable static
LIBTOOL_PIC_OBJECT = $(libtool_libdir)/$$ofile # or none
LIBTOOL_NONPIC_OBJECT = $$ofile # or none

the *_OBJECT definitions assume the absence of shell-active characters
in filenames, which is probably a safe assumption for Makefiles.  In
case libtool configuration finds that $(CC) is not up to e.g. the task
of outputting to object files named in the command line, it just falls
back to running the slow libtool script, with these definitions:

LIBTOOL_BEGIN_CC_COMPILE = $(LIBTOOL) --mode=compile $(CC) -o "$$lofile"

The best news is that we don't really need to modify libtool to play
with these ideas.  We can play with the idea with a new set of
autoconf macros that extracts configuration variables from libtool
with --config and defines the appropriate AC_SUBST variables according
to them, then use custom build rules instead of automake-generated
ones.  If it proves to be a good idea, the macros can be bundled with
libtool, and then automake can gain an option to generate such rules.

It will need a lot of experimenting, and some polishing of the macro
set that I posted above, but I believe you can realize most of the
gains you intend to realize with it, and then you won't be introducing
the need for running yet another program.

Wanna give it a try?

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                 address@hidden,}
CS PhD student at IC-Unicamp        address@hidden,}
Free Software Evangelist                Professional serial bug killer

reply via email to

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