[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: extending automake targets

From: Stefano Lattarini
Subject: Re: extending automake targets
Date: Tue, 12 Oct 2010 12:22:40 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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, let 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.
> > > 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 files have always
> > caused automake to trigger injections of precanned Makefile fragments
> > into the generated (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 (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 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]