Re: extending automake targets

[Ralf Wildenhues]

Hello Stefano,

* Stefano Lattarini wrote on Fri, Oct 08, 2010 at 11:56:55AM CEST:
> On Friday 08 October 2010, Ralf Wildenhues wrote:
> > 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).

While that may be a good reason for discussing both features at the same
time, I don't think it is a good reason for or against the feature.
Rather, it's a good reason for doing design first, then doing tests
and implementation.

> > 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".

Logical semantics are practical, too.  See how users complain about the
complexity of Automake due to many special-cases and such.  Being able
to remember semantics is very practical.  So no, I will reject the
special-case feature
  "with recursive targets @var{foo} provided by the user,
   @command{automake} does not require the @code{foo-local} target
   to be visible to @command{automake}, but with most or all other
   Automake features it does".

for now.  I also think that it is at odds with conditionals.

> > 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.

See below.

> > 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).

This is a good argument.

> > 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.

Sorry, but I reject this notion.  We strive to avoid extra make
recursion if possible, because that induces a number of problems
(with parallelism, with portability of overridden macros, with
performance).

> > maybe even extra make recursions with associated undesirable
> > slowdown effects.

> This should not be the case with the `*-local' and `*-hook' targets

This is wrong.  The hook targets cause extra recursion in at least some
cases, if not always.

> (and in general, I agree that we should strive to avoid extra make
> recursion).

> IMVHO the small increase in flexibility would be worth the very tiny
> decrease in consistency.

I'm afraid we have to agree to disagree on this point then.  I don't
think the primary user base Automake should cater to is users hiding
rules from automake in GNUmakefile files, and giving up consistency
in order to allow them to save writing three lines of Makefile.am code.
I also don't think this use base makes up a very large part of the
overall Automake use base.

I am two thirds through with the review of your posted 3-part patch
series; you might want to wait with updating it until I've finished it,
in order to avoid extra work.

Thanks,
Ralf