automake
[Top][All Lists]
Advanced

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

ideas for speeding up compile mode


From: Ralf Wildenhues
Subject: ideas for speeding up compile mode
Date: Fri, 13 May 2005 17:06:12 +0200
User-agent: Mutt/1.4.1i

[ 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




reply via email to

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