Re: Recursive targets for the user

[Stefano Lattarini]

At Monday 02 August 2010, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Mon, Aug 02, 2010 at 12:10:10PM CEST:
> > At Sunday 01 August 2010, Ralf Wildenhues wrote:
> > > So, here's the deal: currently, Automake has
> > > 
> > >   RECURSIVE_TARGETS
> > >   RECURSIVE_CLEAN_TARGETS
> > >   AM_RECURSIVE_TARGETS
> > 
> > Is there any good reason (apart from naybe
> > backward-compatibility) for keeping these as three separate
> > variables?
> 
> Well, yes.  clean targets need to a different subdir traversal
> order, and currently, the latter lists more than the sum of the
> former: it also lists targets that invoke `make' recursively
> within the same directory.  The latter is needed in some cases
> (mostly for hidden dependencies), and listing them is needed in
> order to avoid unwanted parallel execution; writing a section
> about this necessity has been on my todo list for a while: the
> deal is that you should not run make -jN T1 T2
> 
> if both T1 and T2 are listed in $(AM_RECURSIVE_TARGETS).
OK, thanks for the explanation.

> And yes, backward compatibility is very important, too.  I've
> checked codesearch now, these variables are used elsewhere
> already.  :-/
> 
Well, that was somewhat predictable, since the names of these 
variables seem to suggest that they're not internal variables.

Maybe it would be a good idea to go on with renamings:
  RECURSIVE_TARGETS => am__RECURSIVE_TARGETS ...
  RECURSIVE_CLEAN_TARGETS => am__RECURSIVE_CLEAN_TARGETS
  AM_RECURSIVE_TARGETS => am__AM_RECURSIVE_TARGETS
and deprecate the old RECURSIVE_TARGETS etc. names (while still 
retaining them for, say, a couple of years).  WDYT?

> > 
> > > 1) What to name them?
> > > 
> > >   RECURSIVE_USER_TARGETS
> > >   RECURSIVE_USER_CLEAN_TARGETS
> > >   ALL_RECURSIVE_USER_TARGETS
> > 
> > What about `EXTRA_RECURSIVE_TARGETS' etc. instead?
> 
> Ah, that's a good idea; thanks.
> 
> > Also, I'd like to have a way to specify a recursive targers which
> > should recurse in a limited set of a projects' subdirectories,
> > and not in all of $(SUBDIRS).  Do you think this would be
> > possible/worthwhile?
> 
> Can you give an example what this would be good for?
Yes, I'd like to be able to do what proposed in this old patch series 
of mine:
 <http://www.mail-archive.com/address@hidden/msg01848.html>
without having to recurse to ugly cut-and-paste from lib/am/subdirs.am 
internals, like this:

  ## Factor out non-obvious shell code common to different targets.
  recurse_in_subdirs_cmd = \
    fail= failcom='exit 1'; \
    for f in x $$MAKEFLAGS; do \
      case $$f in \
        *=* | --[!k]*);; \
        *k*) failcom='fail=yes';; \
      esac; \
    done; \
    for subdir in $$subdirs; do \
      (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $@) || eval $$failcom; \
    done; \
    test -z "$$fail"

The same holds for e.g. the `recheck' target provided in the top-level 
Automake's own Makefile.am, where we again can see cut-and-paste from 
(old and buggy!) lib/am/subdirs.am internals:

  .PHONY: recheck
  recheck:
  @failcom='exit 1'; \
  for f in x $$MAKEFLAGS; do \
    case $$f in \
      *=* | --[!k]*);; \
      *k*) failcom='fail=yes';; \
    esac; \
  done; \
  for subdir in $(TEST_SUBDIRS); do \
    (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $@) || eval $$failcom; \
  done; \
  test -z "$$fail"

> My idea was
> that if the user adds a recursive target but then doesn't specify
> an *-am rule in some directory, that the rule would just traverse
> that directory without doing anything by default.
But would it still recurse in that directory's subdirectories? If yes, 
everything's fine with your approach (even if we could then IMHO find 
a better naming than `*-am' for recusrive rules, but this is a minor 
point).

Otherwise, if I wanted a recursive target `foo' descending in say, 
bar/tests/ and baz/quux/tests/,  it would still be necessary for
me to add dummy `foo-am' (or `foo'?) targets to bar/Makefile.am, 
baz/Makefile.am and baz/quux/Makefile.am, and a dummy dependency like 
`foo-am: foo' to bar/tests/Makefile.am and baz/quux/tests/Makefile.am.

> So your suggestion would be optimization only, right?
Not exactly; I just wanted to make it easier for the maintainer to 
write recursive rules without adding too much boilerplate code.
I don't mind an extra recursion here and there (which the current 
automake already does quite often, BTW).

Have I managed to make my point clear this time?

Thanks,
  Stefano