[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:
> >
> > ============
> > EXTRA_PROGRAMS =
> >
> > DANCE_PROGS = dance1 dance2 dance3
> > EXTRA_PROGRAMS += $(DANCE_PROGS)
> > 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
> EXTRA_PROGRAMS += $(SWIM_PROGS)
> 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
> > dance: $(EXTRA_DANCE_PROGRAMS)
> > ./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
either.
> Since this would be a new feature, and pose a small incompatibility:
> EXTRA_FOO_PROGRAMS = p
> 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
Cheers,
--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759