* Stefano Lattarini wrote on Thu, Oct 07, 2010 at 09:27:53PM CEST: > On Thursday 07 October 2010, Ralf Wildenhues wrote: > > The *-am naming is unfortunately used by several packages already too > > (yes, they override e.g., all-am) > IMVHO, they are blatantly violating automake namespace here, and thus > should be ready to adapt to changes in automake internals. We souldn't > be hold back by such abuses of internal details. > > and I'm not sure whether I want to break that. > Well, I'm pretty sure I want ;-) > > What we could do for the sake of backward-compatibility is to keep > for some time the old `foo-am' and `foo-recursive' targets as "alias" > to resp. the new `foo-local' and `foo' ones: > foo-am: foo-local > foo-recursive: foo > so that packages which used our internals in saner ways could still > work (for some time).
But using -local for this is pretty inconsistent, too. foo-local targets exist to extend foo targets. The internal foo-am targets are the nonrecursive part of the foo targets. They serve different purposes, and mixing that up is not a good idea. So no, we shouldn't use -local. At least not if you want consistency between user-provided recursive targets and automake-provided ones. And if we need another suffix anyway, might as well use -am. > > > Then we could let the user implement his own recursive > > > targets in a uniform fashion w.r.t. automake-generated recursive > > > targets (and thus also still share the rule code text). > > Not sure what you mean here. > I mean that the user-defined recursive targets should be as similar as > possible to the automake-defined ones in the design, behaviour, and > implementation, all as transparently to the user as possible. See above. Cheers, Ralf
