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
