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?
>> +
>> +@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
>
> The example looks good, and I want to thank you for introducing this
> obvious way to factor out duplicative hand-rolled make subdir
> recursion in projects that need it,
>
Thanks. A most welcome appreciation :-)
> particularly in light of
> "Recursive Make Considered Harmful", which might have caused a lesser
> man to believe this patch is counterproductive by catering to sadly
> outdated troglodytes.
>
As I understands it, the point of "Recursive Make Considered Harmful"
is not that make recursion is always bad, its point is that recursion
is bad where it is artificial and breaks the make DAG, or lies about
the dependencies.
So there's no point in trying to sabotage the users who use make
recursion: if they are doing that for a good reason, we should support
their use cases (especially because it's easy to do so: my patch is
small and safe and simple), and if they do so for the wrong reasons,
let them shoot themselves in the foot -- that is the UNIX way.
Thanks,
Stefano
