[ CC to automake because it is involved -- see below ]
Have been thinking a little about speeding up compile mode.
Unfortunately, there is no trivial trick like for link mode when
what you do is compile thousands of tiny translation units -- the large
constant involved with slow shell script execution speed is just there,
and I don't see much area for significant improvement in
func_mode_compile either.
This lends oneself to suggest a look at other options which immediately
come to mind (I try to maximize positive net effect versus our
implementation/maintenance costs, while keeping backward
incompatibilites low):
1) Implement a caching mechanism like libtool-cache.
Could be done, but seems kind of backwards because it is far from optimal,
at least with the necessary cache locking and reparsing of the command
line involved. Still, I see this as a viable option because it might
easily be the least amount of implementation work. Backward
compatibility: trivial.
2) Reimplement compile mode in a compiled language (e.g. C).
Viable, too, and less backward. May pave a way for reimplementing other
modes in the long run too. Trivial to make backward-compatible, too.
BTW, I would not write either ones (ltcompile or ltcache) in perl:
its high startup costs won't help to kill this issue _once and for all_
(plus Gary hates perl :-)
3) Fold compile mode completely into Automake snippets/the resulting
Makefile. I wonder why this has not been done before, at least for the
default rules (per-target rules could lead to a large blowup of the
resulting Makefile.in).
Let me be a little more specific here:
Libtool compile mode does little more than issue one or two compile
commands, rewrite the output file name, add PIC flag, then write a .lo
file. Oh, and guess the tagname to use, in case the user hasn't
provided one. And it allows a couple of additional flags like
--silent, --debug, --dry-run,
-prefer-pic, -prefer-non-pic, -static, -shared.
Let's forget about the cmdline flags for a moment now.
Could Libtool just do sth like (including setting the values)
AC_SUBST([lt_objdir])
AC_SUBST([lt_pic_flag])
and Automake then create sth like
LT_PIC_COMPILE = ...
LT_NONPIC_COMPILE = ...
lt_lo2o = sed 's|\.lo$|.o|'
lt_lo2oo = sed 's|\.lo$|.o|' -e '/[\/\\]/{ s|.*[/\\]|&$(lt_objdir)/|; }'
lt_suppress = >/dev/null 2>&1
LT_COMPILE = obj=`$(ECHO) "X$<" | $lt_lo2o` && \
lobj=`$(ECHO) "X$<" | $lt_lo2oo` && \
$(LT_PIC_COMPILE) -c -o $$lobj $< && \
$(LT_NONPIC_COMPILE) -c -o $$obj $< $(lt_suppress) && \
$(LT_LOFILE) "$$obj" "$$lobj" && \
(echo blablabla; \
echo "pic_object='$$lobj'" \
# ... ) > $@
.c.lo:
$(LT_COMPILE)
What am I missing?
- Locking is taken care of by `compile', Automake adds `--tag'.
- For non Automake users, we could provide a Makefile snippet to include.
- We could enable this with a LT_INIT and/or AM_INIT_AUTOMAKE flag in
order to avoid destroying backwards incompatibility in case the user
wants to be able to use the additional libtool options.
- Alternatively, we could test flags in the make rule, which might get
messy, though.
- In the simplest case, corresponding to what we have now (minus libtool
--mode=compile command line options), we could add two Automake
conditionals LT_BUILD_PIC and LT_BUILD_NONPIC as to whether nonpic or
pic objects will be built. lt_suppress should be possible to be put
in such conditional as well, I believe.
- In a more advanced setting, Automake may actually be able to "decide"
that non-pic objects are sometimes not necessary (for convenience archives).
Thoughts?
Should I start to learn the innards of Automake for hacking up a patch?
I have no idea how to realize the last item, but it sounds intriguing.
(These ideas may not be new, BTW).
Regards,
Ralf
