On Dec 3, 2003, Mohan Embar <[EMAIL PROTECTED]> 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
flags.
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/ltmain.sh, 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; \
$(LIBTOOL_BEGIN_COMPILE_CC) FLAGS foo.c \
$(LIBTOOL_END_COMPILE_CC)
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)
LIBTOOL_BEGIN_COMPILE_CC = set fnord \
LIBTOOL_END_COMPILE_CC = ; shift 1; \
{ 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"
LIBTOOL_END_CC_COMPILE =
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 http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org}
CS PhD student at IC-Unicamp[EMAIL PROTECTED], gnu.org}
Free Software EvangelistProfessional serial bug killer
