Re: -recursive

[Akim Demaille]

>>> "Akim" == Akim Demaille <address@hidden> writes:
 Akim> Maybe it is time to introduce higher level constructs, say
 Akim> .AM-RECURSIVE: foo

 Akim> which would handle all the tedious binding of foo-am, foo-recursive
 Akim> to foo, plus the .PHONYzation etc.  

 > Some user also asked how he could define his own recursive target.
 > Would this help?

That would make it less implementation dependent anyway: the user
would not know about -recursive vs. -am etc.  Actually, I don't
really understand the implementation in multilib, do you?

if %?SUBDIRS%
all-recursive: all-multi
install-recursive: install-multi
else !%?SUBDIRS%
all-am: all-multi
install-am: install-multi
endif !%?SUBDIRS%

(and similarly for other targets).  Why not just bind it to -am?
It's coming from 

2001-05-27  Tom Tromey  <address@hidden>

            * automake.in (handle_multilib): Only add multilib support
              code at
              top level.
              * lib/am/multilib.am: Handle invocation of *-multi
              targets
              differently for SUBDIRS and non-SUBDIRS Makefiles.
              * m4/multi.m4 (AM_ENABLE_MULTILIB): Removed erroneous
              comment.
              Only add multilib code when the Makefile in question is
              actually
              rebuilt.

But there is not much information in there :(

 Akim> We really lack abstraction in the definition of the am
 Akim> files.

 > Agreed.  By the way, when will it be possible to have a Bison-generated
 > parser for Makefile.am's? 

Who knows :(  Not me.  So many things are to be done in Bison...

 > There are many simplifying construct we could introduce with this.

Yep, I agree.  Nevertheless, many of them would not require evolved
syntax.  Something like

.RECURSIVE: all

etc. is easy to handle.  There are probably many such features already
available.