On Monday 11 October 2010, Ralf Wildenhues wrote:
> 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.
IMHO the current implementation of the `*-local' targets is more complex
and special-cased than the one proposed by me.
> 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.
OK, and even if I disagree with you on this, I will amend my patch along
these lines (if it's not too difficult).
> I also think that it is at odds with conditionals.
Why?
> > > 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.
Well, it's basically taken from the automake manual ;-)
> > > 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).
OK; but this might be a problem for hooks, not for `*-local' targets
(and maybe we could even rethink how hooks are implemented, to avoid
make recursion as much as possible; but this is out of the scope of
the current discussion, so let's drop it for now).
> > > 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.
OK, sorry for the ignorance; but see above.
> > (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.
OK, thanks for the tip.
As an aside, I must warn you that I'm experiencing harware problems,
so I might not be able to reply right away (or at all) to your mails
in the next days. Sorry about the inconvenient.
Regards,
Stefano
