[Top][All Lists]

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

Re: Need more EXTRA_PROGRAMS variables

From: Behdad Esfahbod
Subject: Re: Need more EXTRA_PROGRAMS variables
Date: Fri, 29 Jun 2007 01:40:07 -0400

On Thu, 2007-06-21 at 20:24 +0200, Ralf Wildenhues wrote:
> * Behdad Esfahbod wrote on Thu, Jun 21, 2007 at 01:42:18AM CEST:
> > On Tue, 2007-06-19 at 09:18 +0200, Ralf Wildenhues wrote:
> > > 
> > > All fair.  Except I simply don't see a use case for this yet, nor do I
> > > see what `something' should mean in this case.  If you can create a
> > > sensible use case, let's see how to implement it.  IOW: where do you
> > > need EXEEXT rewriting for something that is not an optionally built
> > > program?
> > 
> > Ok, maybe I have a wrong idea of what the committed fix was.  I want
> > to be able to have something like this work:
> > 
> > ============
> > 
> > DANCE_PROGS = dance1 dance2 dance3
> > dance: $(DANCE_PROGS)
> >     ./perform-dance # uses progs dance1, dance2, and dance3
> > ============
> > 
> > Now does automake rewrite DANCE_PROGS to include EXEEXT?
> No, it doesn't.  Thanks for the example, I think I understand now
> and I see that this requires another variable, e.g., in order to also
> have
> SWIM_PROGS = swim1
> swim: $(SWIM_PROGS)
>         ./perform_swim # ...
> in which case you could not just use $(EXTRA_PROGRAMS) as prerequisite
> of dance any more (as that would be suboptimal).
> > ============
> > EXTRA_DANCE_PROGRAMS = dance1 dance2 dance3
> >     ./perform-dance # uses progs dance1, dance2, and dance3
> > ============
> > 
> > It will do. (and since it's a "EXTRA_" var, there is no need for
> > DANCEdir to be defined).
> I'm not yet totally convinced that this is the best solution, but
> currently I fail to see technical issues with it.  Are you motivated to
> work on a patch?  If yes, then look at automake.in:handle_programs and
> automake.in:am_install_var to get going.  If you'd rather not venture
> into that, it'd help a lot already if you wrote a documentation patch
> and (used above in) a test.

My Perl skills are non-existent, but I'll try to give the doc patch a
shot.  Though I still have to reply to a mail from you about the libtool
feature that I asked for and you were nice enough to implement.

> FWIW, here's a couple of random ideas about why this naming is maybe
> not ideal: it deviates from there where_HOW principle used in Automake.
> The EXTRA_ bit is all clear, but the DANCE_ bit suddenly carries no
> obvious meaning, unlike other variables.  Such special cases IMHO make
> Automake's semantics more difficult to grasp for newcomers (and they
> also make the documentation more difficult to write in a concise
> manner).  OTOH I don't see an obvious better choice either.

Yeah, I totally understand that.  But I don't see any other alternatives

> Since this would be a new feature, and pose a small incompatibility:
>   EXTRA_FOOdir = $(bindir)
> will be treated differently with the patch than without the change
> (wrt. what's build at 'all' time and what's installed),
> this change is suitable for HEAD but not for branch-1-10.

Right.  Though it's hard for me to imagine any way to add new features
without such an effect.

> Thanks for your patience with me.

Thank *you*.  I always get pissed off when people write to me about some
code I maintain and propose a solution without first presenting their
problem, but then when it's my turn I do the same too :).

> Cheers,
> Ralf


"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759

reply via email to

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