extending automake targets (was: Re: Recursive targets for the user)

[Stefano Lattarini]

On Friday 08 October 2010, Ralf Wildenhues wrote:
> Hello Stefano,
> 
> * Stefano Lattarini wrote on Fri, Oct 08, 2010 at 02:46:58AM CEST:
> > What I'd like to do is to allow the developers to extend the nonrecursive
> > part of any recursive `foo' rule (be it user-defined or automake-defined)
> > with a simple:
> > 
> >   foo-local: foo-extra-deps
> > 
> > *without causing automake to tweak the generated Makefile.in or to take
> > different codepaths*.
> 
> This is a valid feature request, but orthogonal to the feature request
> we have discussed so far.
Yes, but I hadn't understand that at first :-(
Now I do (in fact I stated that it should be done in a follow-up patch).

> Can we also keep its discussion and its eventual addition separate, for
> both user-defined and automake-defined recursive targets, please?
Not really, because,  *for user targets only*, I've already implemented
that feature (and added tests for it) in my patch (it was easier than
not implementing it, and its implementation requires no extra forks,
relying exclusively on the make dependency graph).

> I don't yet see much chance for regression yet, but the feature does
> violate the "given Makefile.am, let Makefile.in be as simple as
> possible" development guide line.  It would not be easy to draw a
> consistent line:
True; but as the pythonistas say, "practicality beats purity".
> what about *-hook extensions defined only in GNUmakefile?
I think we should support them too in the future, if it's not too
much work.

> What about things like BUILT_SOURCES?
Well, assignments of special variables in Makefile.am files have always
caused automake to trigger injections of precanned Makefile fragments
into the generated Makefile.in (plus other tweakings); this is the very
basic tenet and working principle of Automake.  So it's fair to expect
that such definitions *must* be in Makefile.am (and not in a wrapping
GNUmakefile) for the automake-generated rules to behave correctly.
This is where I'd draw the line (theoretically, at least; some things
that should be theoretically possible might not be pratically possible
for implementation or historical reasons, but that's a wholly different
matter).

> Either of those would trigger extra forks,
Anyway, many automake-generated rules are already so fork-ridden that
the extra forks we are speaking about here wouldn't make any noticeable
difference -- but would, on the other hand, provide us with more
flexibility.
> maybe even extra make recursions with associated undesirable
> slowdown effects.
This should not be the case with the `*-local' and `*-hook' targets
(and in general, I agree that we should strive to avoid extra make
recursion).
> Then what about special variables like bin_PROGRAMS?
See above.
> If we don't have any _PROGRAMS in
> Makefile.am (or included files), then we completely avoid the
> compilation machinery; OTOH, it only needs a
>   noinst_PROGRAMS =
> 
> line to enable it, just as it only needs a
>   all-local:
> 
> line to enable the -local hook for all (and such a line can easily be
> script-added to Makefile.am files in need).  IOW, the current behavior
> is very consistent, while your proposed extension is less consistent.
IMVHO the small increase in flexibility would be worth the very tiny
decrease in consistency.

Regards,
  Stefano