On Thursday 07 October 2010, Ralf Wildenhues wrote: > Hello Stefano, > > * Stefano Lattarini wrote on Wed, Oct 06, 2010 at 02:56:08AM CEST: > > On Sunday 01 August 2010, Ralf Wildenhues wrote: > > > > 3) Whether to document the s/$/-am/ rule for the per-directory > > > target so it then also holds for user-provided recursive rules. > > > (If yes, then we could share the rule code text between both.) > > > What about getting rid of the old `foo-am' targets altogheter, > > substituting them with `foo-local' instead, which is more natural and > > intuitive? > > 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). Anyway, all of this is (luckily!) orthogonal to the issue under discussion here (it would pertain to a follow-up refactoring or optimization). > > 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. Regards, Stefano
