Re: [RFC] recursion: support user-defined recursive targets

[Dave Hart]

On Sat, Jun 30, 2012 at 13:16 UTC, Stefano Lattarini wrote:
> Hi Dave, thanks for the feedback.
>
> On 06/30/2012 12:54 PM, Dave Hart wrote:
>> On Sat, Jun 30, 2012 at 08:56 UTC, Stefano Lattarini wrote:
>>> And here is the documentation, basically adapted from the commit message.
>>>
>>> Comments welcome.
>>>
>>> Regards,
>>>  Stefano
>>>
>>> -*-*-*-
>>>
>>> diff --git a/doc/automake.texi b/doc/automake.texi
>>> index 87776b3..2bddc15 100644
>>> --- a/doc/automake.texi
>>> +++ b/doc/automake.texi
>>> @@ -4204,6 +4204,32 @@ will be built.  It is customary to arrange test 
>>> directories to be
>>>  built after everything else since they are meant to test what has
>>>  been constructed.
>>>
>>> +In addition to the built-in recursive targets defined by Automake
>>> +(@code{all}, @code{check}, etc.), the developer can also define his
>>> +own recursive targets.  That is done by specifying the name of such
>>> +targets as arguments to the Automake-provided autoconf macro
>>> address@hidden  Automake will then generate
>>> +stub rules to automatically handle recursion for such targets; the
>>> +developer can define real actions for them defining a corresponding
>>> address@hidden target.
>>
>> The last sentence is written a bit too much from the Automake
>> implementor's perspective rather than the Automake user.  I struggled
>> to come up with something better, but may have failed.
>>
>> Automake generates rules to handle the recursion for such targets; the
>> developer defines corresponding @code{-local} targets in Makefile.am
>> for each directory participating in satisfying the recursive target.
>>
> Ah, but the nice thing about this new feature is that you don't need
> to define a 'foo-local' target in each of your Makefiles in order to
> support a recursive 'foo' target!  You only have to define 'foo-local'
> where it has actually something to do.  This is not clear from your
> formulation IMO.  Do you have an alternative formulation that takes
> my clarification into account?

I tried to communicate that, but we could add "Automake generates
corresponding stub @code{-local} targets when Makefile.am does not
provide such target."

>>> +
>>> address@hidden
>>> +% @kbd{cat configure.ac}
>>> +AC_INIT([pkg-name], [1.0]
>>> +AM_INIT_AUTOMAKE
>>> +AM_EXTRA_RECURSIVE_TARGETS([foo])
>>> +AC_CONFIG_FILES([Makefile sub/Makefile])
>>> +AC_OUTPUT
>>> +% @kbd{cat Makefile.am}
>>> +SUBDIRS = sub
>>> +foo-local:
>>> +       address@hidden This will be run by "make foo".
>>> +% @kbd{cat sub/Makefile.am}
>>> +foo-local:
>>> +       address@hidden This too will be run by a "make foo" issued either in
>>> +       address@hidden the 'sub/' directory or in the top-level directory.
>>> address@hidden example
>>> +
> In light of my explanation above, I now think this example should be
> extended as follows:
>
>  % @kbd{cat Makefile.am}
>  SUBDIRS = sub
>  foo-local:
>       @echo This will be run by "make foo".
>  % @kbd{cat sub/Makefile.am}
>  SUBDIRS = src
>  % @kbd{cat sub/src/Makefile.am}
>  foo-local:
>       @echo This too will be run by a "make foo" issued either in
>       @echo the 'sub/src' directory, in the 'sub/' directory, or
>       @echo in the top-level directory.
>
>>> address@hidden Conditional Subdirectories
>>> address@hidden Conditional Subdirectories
>>> address@hidden Subdirectories, building conditionally

I agree highlighting the intermediate directory doesn't need to
provide a foo-local target improves the example.

Cheers,
Dave Hart