[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future plans for Autotools
From: |
Zack Weinberg |
Subject: |
Re: Future plans for Autotools |
Date: |
Mon, 25 Jan 2021 09:47:55 -0500 |
On Mon, Jan 25, 2021 at 8:38 AM Paul Smith <psmith@gnu.org> wrote:
> On Sun, 2021-01-24 at 16:26 -0700, Tom Tromey wrote:
> > I think it would be good. I'm curious if it is known to be faster or
> > if that's just an expectation. I'd also be very interested to learn
> > which changes would make the result faster.
>
> Speaking for myself I'm not convinced requiring GNU make would be a lot
> faster.
>
> The only thing that would make much of a performance difference, I
> think, is if we are able to replace lots of shell invocations with
> built-in make functions like wildcard, if, etc. However I'm not sure
> there's enough opportunity for that to matter.
I'm not at all familiar with Automake's internals, but the reason I
suggested taking advantage of GNU make extensions was the potential
for _complexity_ reduction of the generated Makefile, not performance.
For instance, this generated rule from one of my other projects
test/ka_bcrypt_a-ka-tester.o: test/ka-tester.c
$(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)
$(test_ka_bcrypt_a_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT
test/ka_bcrypt_a-ka-tester.o -MD -MP -MF
test/$(DEPDIR)/ka_bcrypt_a-ka-tester.Tpo -c -o
test/ka_bcrypt_a-ka-tester.o `test -f 'test/ka-tester.c' || echo
'$(srcdir)/'`test/ka-tester.c
$(AM_V_at)$(am__mv) test/$(DEPDIR)/ka_bcrypt_a-ka-tester.Tpo
test/$(DEPDIR)/ka_bcrypt_a-ka-tester.Po
would be completely unnecessary if Automake could rely on
target-specific variable values, and would be substantially simpler if
it could rely on $< working in all rules.
Automake _does_ make heavy use of shell constructs embedded inside
frequently-executed rules, for instance
.c.o:
$(AM_V_CC)depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.o$$||'`;\
$(COMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
$(am__mv) $$depbase.Tpo $$depbase.Po
which looks like it could become
%.o: %.c
$(AM_V_CC)$(COMPILE) -MT $@ -MD -MP -MF $(@D)/$(DEPDIR)/$(*F).Tpo \
-c -o $@ $<
$(AM_V_at)$(am__mv) $(@D)/$(DEPDIR)/$(*F).Tpo $(@D)/$(DEPDIR)/$(*F).Po
and enable Make to bypass the shell altogether. Might be worth
benchmarking on a big program. Has to be an executable, not a
library, though; for libraries, the overhead of the libtool script is
going to dominate.
zw
- Re: Future plans for Autotools, (continued)
Re: Future plans for Autotools, Tom Tromey, 2021/01/21
- Re: Future plans for Autotools, John Calcote, 2021/01/21
- Re: Future plans for Autotools, Tom Tromey, 2021/01/24
- Re: Future plans for Autotools, Paul Smith, 2021/01/25
- Re: Future plans for Autotools,
Zack Weinberg <=
- Re: Future plans for Autotools, Paul Smith, 2021/01/25
- Re: Future plans for Autotools, Nick Bowler, 2021/01/25
- Re: Future plans for Autotools, John Calcote, 2021/01/25
- Re: Future plans for Autotools, Paul Smith, 2021/01/25
- Re: Future plans for Autotools, Bob Friesenhahn, 2021/01/25
- Re: Future plans for Autotools, Nick Bowler, 2021/01/25
- Re: Future plans for Autotools, Paul Smith, 2021/01/26
Re: Future plans for Autotools, Bob Friesenhahn, 2021/01/25
Re: Future plans for Autotools, David A. Wheeler, 2021/01/25
Re: Future plans for Autotools, Paul Eggert, 2021/01/25