automake
[Top][All Lists]
Advanced

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

Re: Recursive targets for the user


From: Stefano Lattarini
Subject: Re: Recursive targets for the user
Date: Fri, 8 Oct 2010 02:46:58 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

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








reply via email to

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