Hi Ralf, and thanks for your answers. They're helping me a lot.
On Friday 08 October 2010, Ralf Wildenhues wrote:
> * Ralf Wildenhues wrote on Thu, Oct 07, 2010 at 09:32:19PM CEST:
> > * Stefano Lattarini wrote on Thu, Oct 07, 2010 at 09:27:53PM CEST:
> > > 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.
>
> I think I should restate this, because my previous post was a bit
> confused:
>
> I think we don't need to publish the *-am interface. We only publish
> that with a recursive rule foo,
> foo is the public target
> foo-local is the thing the user can specify to extend it in this
> Makefile.am
>
> and then
> foo-am is the nonrecursive (generated) part of the rule that
> mostly either does nothing or depends on foo-local if
> given
> foo-recursive is the recursive (generated) part
Perfect explanation. Thank you.
> What am I overlooking?
Nothing, I was just confused; I pondered upon the question, I reached the
same conclusion so well summarized by you above, I wrote a reply to your
previous mail... and only then I saw your latest mail :-(
Anyway, my reply touched some further points that I regard as imporant,
so I'll go on and quote it here anyway.
-*-*-*-
On Thursday 07 October 2010, Ralf Wildenhues wrote:
> * 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.
Good point. Now I see that I was confused because I was unduly mixing
two different concerns.
Let me (try to) explain myself better.
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 would IMHO simplify the semantic and the implementation of the
`*-local' hooks, and would make their use more flexible.
The behaviour I have in mind would allow the following monstruosity
to work out of the box:
RECURSIVE_TARGETS_WITH_EXTRA_DEPS = \
@A_CONFIGURE_TIME_USER_RECURSIVE_TARGET@ \
another-user-recursive-target
RECURSIVE_TARGETS_WITH_EXTRA_DEPS += check installcheck
LOCAL_TARGETS_WITH_EXTRA_DEPS = \
$(RECURSIVE_TARGETS_WITH_EXTRA_DEPS:=-local)
$(LOCAL_TARGETS_WITH_EXTRA_DEPS): extra-deps
More importantly, this would work too:
$ : > Makefile.am
$ cat > GNUmakefile <<END
include Makefile
all-local: maint-rule
maint-rule:
@echo 'IT WORKS!'
END
$ automake
$ gmake
IT WORKS!
Currently, the latter example would work only if a literal `foo-local'
target is added to Makefile.am; which makes the wrapping of automake
generated Makefiles more difficult, and hopelessly non-transparent
for the original Makefile.am writer.
My half-baked patch (still to be posted, as it's not yet finished)
enable the desirable behaviour described above *for user recursive
targets only*; but I think I can extend it also to automake-generated
recursive targets, and do so in a backward-compatible way. That's for
a follow-up patch, though.
Regards,
Stefano
