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
>>> +@code{AM_EXTRA_RECURSIVE_TARGETS}. Automake will then generate
>>> +stub rules to automatically handle recursion for such targets; the
>>> +developer can define real actions for them defining a corresponding
>>> +@code{-local} 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."
>>> +
>>> +@example
>>> +% @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:
>>> + @echo This will be run by "make foo".
>>> +% @kbd{cat sub/Makefile.am}
>>> +foo-local:
>>> + @echo This too will be run by a "make foo" issued either in
>>> + @echo the 'sub/' directory or in the top-level directory.
>>> +@end 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.
>
>>> @node Conditional Subdirectories
>>> @section Conditional Subdirectories
>>> @cindex Subdirectories, building conditionally
I agree highlighting the intermediate directory doesn't need to
provide a foo-local target improves the example.
Cheers,
Dave Hart
