Hi, The build can pass by change the server and client order in PROGRAMS define. The server_LIBS can define after first call of client. Just like next: ===================== PROGRAMS = client server .PHONY: all all: $(PROGRAMS) client_LIBS := protocol define PROGRAM_template # inside macro test server_LIBS := priv protocol $(1): cc $($(1)_LIBS) -o $$@ endef $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog)))) =====================
regards. carl shen 2009/3/17 <[email protected]> > Send Help-make mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnu.org/mailman/listinfo/help-make > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Help-make digest..." > > > Today's Topics: > > 1. Re: define issues (Philip Guenther) > 2. Re: Help-make Digest, Vol 76, Issue 7 (xiangfeng shen) > 3. Re: define issues (Eli Zaretskii) > 4. Re: define issues (Philip Guenther) > 5. RE: define issues (Appleton, R. (Rick)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 16 Mar 2009 16:47:16 -0700 > From: Philip Guenther <[email protected]> > Subject: Re: define issues > To: "Appleton, R. (Rick)" <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2009/3/16 Appleton, R. (Rick) <[email protected]>: > > I'm having issues using defines in a Makefile. > > The following makefile: > > > > ===================== > > PROGRAMS = server client > > > > .PHONY: all > > all: $(PROGRAMS) > > > > server_LIBS := priv protocol > > client_LIBS := protocol > > > > define PROGRAM_template > > > > $(1): > > cc $($(1)_LIBS) -o $$@ > > > > endef > > > > $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog)))) > > ===================== > > > > generates this output > > cc priv protocol -o server > > cc protocol -o client > > Could you elaborate on why you choose to use $(eval) for that? I ask > because > 1) $(eval) has proven to be difficult for people to understand and > reason about, and > 2) the problem given can be solved without using $(eval): > > ----- > PROGRAMS = server client > > .PHONY: all > all: $(PROGRAMS) > > server_LIBS := priv protocol > client_LIBS := protocol > > $(PROGRAMS): > cc $($...@_libs) -o $@ > ----- > > Practically all the uses of $(eval) that I've seen posted here have > been buggy, unnecessary, or both. > > > > yet the following file > ... > > generates this (unexpected) output > > cc -o server > > cc protocol -o client > > > > Does anyone have an idea why it might be doing this? > > Makes perfect sense to me. You just have to think about when the > various variable references are being expanded (_before_ $(eval) is > getting the text to evaluate, _during_ that evaluation, or > _afterwards_ when the rule is being processed) versus when the various > variable settings are actually being performed. > > <soapbox> > > Let me apologize in advance if my next statement appears to be a > personal insult. It's not meant as such, as I hope I'll make clear. > > To be blunt, $(eval) should be relegated to the "EXPERTS ONLY" section > of the manual...and if you don't understand what I meant by "before vs > during vs afterwards", then you're not an expert and should not use > it. > > This isn't meant to be a slam on you or the others that have tried to > use $(eval) and been tripped up by how it works. I think $(eval) was > not documented with enough warnings about how non-intuitive it is, so > that it looks like a simple way for people to write more 'procedural' > makefile. In my experience, most users are slightly uncomfortable > with make's declarative operation, so the option to write a makefile > as if it was a procedural language is seductive. The problem is that > $(eval) was designed for the complex cases, where double expansion is > critical, and not for the simple cases, where double expansion is a > trap to drive users insane. > > > Perhaps you get all the above and my mention of > "before/during/afterwards" was all it took for you to see how to solve > your problem. That good, but I strongly suggest you reconsider your > use of $(eval) and whether it's actually necessary or just an attempt > to jam make into a different paradigm of expression. > > Similarly, I suggest to the GNU make maintainers to think *real hard* > about what they can do to ease the support burden that has been > created by $(eval) being freely used by people that think it simpler > than it is, perhaps starting with a pile of warnings and cookbook > examples in the info pages...but I'll leave that to someone who > actually likes $(eval). > > </soapbox> > > > Philip Guenther > > > > > ------------------------------ > > Message: 2 > Date: Mon, 16 Mar 2009 19:32:24 -0800 > From: xiangfeng shen <[email protected]> > Subject: Re: Help-make Digest, Vol 76, Issue 7 > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > The macro PROGRAM_template do not expand by first parse when reading the > makefile. > So the server_LIBS is not defined at all when calling macro > PROGRAM_template. > The $($(1)_LIBS) expand to nothing when called. > > regards. > carl shen > > 2009/3/16 <[email protected]> > > > Send Help-make mailing list submissions to > > [email protected] > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.gnu.org/mailman/listinfo/help-make > > or, via email, send a message with subject or body 'help' to > > [email protected] > > > > You can reach the person managing the list at > > [email protected] > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Help-make digest..." > > > > > > Today's Topics: > > > > 1. define issues (Appleton, R. (Rick)) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 16 Mar 2009 09:05:10 +0100 > > From: "Appleton, R. (Rick)" <[email protected]> > > Subject: define issues > > To: <[email protected]> > > Message-ID: > > <[email protected]> > > Content-Type: text/plain; charset="iso-8859-1" > > > > I'm having issues using defines in a Makefile. > > The following makefile: > > > > ===================== > > PROGRAMS = server client > > > > .PHONY: all > > all: $(PROGRAMS) > > > > server_LIBS := priv protocol > > client_LIBS := protocol > > > > define PROGRAM_template > > > > $(1): > > cc $($(1)_LIBS) -o $$@ > > > > endef > > > > $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog)))) > > ===================== > > > > generates this output > > cc priv protocol -o server > > cc protocol -o client > > > > yet the following file > > ===================== > > PROGRAMS = server client > > > > .PHONY: all > > all: $(PROGRAMS) > > > > client_LIBS := protocol > > > > define PROGRAM_template > > > > # The following line has moved inside the define > > server_LIBS := priv protocol > > > > $(1): > > cc $($(1)_LIBS) -o $$@ > > > > endef > > > > $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog)))) > > ===================== > > > > generates this (unexpected) output > > cc -o server > > cc protocol -o client > > > > Does anyone have an idea why it might be doing this? > > > > My GNU Make version is 3.80 > > This e-mail and its contents are subject to the DISCLAIMER at > > http://www.tno.nl/disclaimer/email.html > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://lists.gnu.org/pipermail/help-make/attachments/20090316/256949fe/attachment.html > > > > ------------------------------ > > > > _______________________________________________ > > Help-make mailing list > > [email protected] > > http://lists.gnu.org/mailman/listinfo/help-make > > > > > > End of Help-make Digest, Vol 76, Issue 7 > > **************************************** > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/help-make/attachments/20090316/9bbaa4a4/attachment.html > > ------------------------------ > > Message: 3 > Date: Tue, 17 Mar 2009 06:16:53 +0200 > From: Eli Zaretskii <[email protected]> > Subject: Re: define issues > To: Philip Guenther <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > > > Date: Mon, 16 Mar 2009 16:47:16 -0700 > > From: Philip Guenther <[email protected]> > > Cc: [email protected] > > > > To be blunt, $(eval) should be relegated to the "EXPERTS ONLY" section > > of the manual...and if you don't understand what I meant by "before vs > > during vs afterwards", then you're not an expert and should not use > > it. > > [...] > > Similarly, I suggest to the GNU make maintainers to think *real hard* > > about what they can do to ease the support burden that has been > > created by $(eval) being freely used by people that think it simpler > > than it is, perhaps starting with a pile of warnings and cookbook > > examples in the info pages...but I'll leave that to someone who > > actually likes $(eval). > > Maybe we should just improve the documentation to better explain what > $(eval) does and how, so that even non-experts will see the light. > What is missing from the current docs that you think should be there > (and I don't mean the warning to stay away)? > > > > > ------------------------------ > > Message: 4 > Date: Mon, 16 Mar 2009 23:55:08 -0700 > From: Philip Guenther <[email protected]> > Subject: Re: define issues > To: Eli Zaretskii <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 16, 2009 at 9:16 PM, Eli Zaretskii <[email protected]> wrote: > ... > > Maybe we should just improve the documentation to better explain what > > $(eval) does and how, so that even non-experts will see the light. > > What is missing from the current docs that you think should be there > > (and I don't mean the warning to stay away)? > > Double-evaluation in various languages has been a source of bugs and > security holes for years, but you don't think people should be warned > away from this? > > "Here folks, see how cleanly this slices your fingers off? Ain't it > great!?! Oh, and the results are completely unlike normal makefiles > and unmaintainable by the people who follow you! Perfect job > security, assuming you keep your job after you've lost your fingers!" > > For myself, I'm not experienced enough in its use to make a > recommendation about how it should be used; I *don't* think it should > be removed, but I'm not going to use it until it's the last resort. > I've dealt with double-eval crap in enough other languages to be able > to see where the problems lie in someone else's usage, but mostly to > not want to go there. > > > Philip Guenther > > > > > ------------------------------ > > Message: 5 > Date: Tue, 17 Mar 2009 09:01:01 +0100 > From: "Appleton, R. (Rick)" <[email protected]> > Subject: RE: define issues > Cc: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you Philip for your response. I've been using this construct in a > top-level Makefile for a non-recursive make system (inspired by > http://blogs.designingpatterns.com/urban-jungle/category/build-systems/make-build-systems/). > The example I posted was just me trying to get a better understanding of how > the system could/would be used. After sending the mail I spent more time > with the actual system (rather than the sample I posted), and got a better > understanding of eval. This morning I was able to spot the error in the > sample as well, so the time spent on the system has definately helped. > > I do agree with you that the eval function is quite difficult to parse for > someone new to it, and the manual (I've been using > http://www.gnu.org/software/make/manual/make.html#Top) could definately be > clearer about it. > > Thanks again for your help, > Rick > > -----Original Message----- > From: Philip Guenther [mailto:[email protected]] > Sent: Tue 3/17/2009 12:47 AM > To: Appleton, R. (Rick) > Cc: [email protected] > Subject: Re: define issues > > 2009/3/16 Appleton, R. (Rick) <[email protected]>: > > I'm having issues using defines in a Makefile. > > The following makefile: > > > > ===================== > > PROGRAMS = server client > > > > .PHONY: all > > all: $(PROGRAMS) > > > > server_LIBS := priv protocol > > client_LIBS := protocol > > > > define PROGRAM_template > > > > $(1): > > cc $($(1)_LIBS) -o $$@ > > > > endef > > > > $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog)))) > > ===================== > > > > generates this output > > cc priv protocol -o server > > cc protocol -o client > > Could you elaborate on why you choose to use $(eval) for that? I ask > because > 1) $(eval) has proven to be difficult for people to understand and > reason about, and > 2) the problem given can be solved without using $(eval): > > ----- > PROGRAMS = server client > > .PHONY: all > all: $(PROGRAMS) > > server_LIBS := priv protocol > client_LIBS := protocol > > $(PROGRAMS): > cc $($...@_libs) -o $@ > ----- > > Practically all the uses of $(eval) that I've seen posted here have > been buggy, unnecessary, or both. > > > > yet the following file > ... > > generates this (unexpected) output > > cc -o server > > cc protocol -o client > > > > Does anyone have an idea why it might be doing this? > > Makes perfect sense to me. You just have to think about when the > various variable references are being expanded (_before_ $(eval) is > getting the text to evaluate, _during_ that evaluation, or > _afterwards_ when the rule is being processed) versus when the various > variable settings are actually being performed. > > <soapbox> > > Let me apologize in advance if my next statement appears to be a > personal insult. It's not meant as such, as I hope I'll make clear. > > To be blunt, $(eval) should be relegated to the "EXPERTS ONLY" section > of the manual...and if you don't understand what I meant by "before vs > during vs afterwards", then you're not an expert and should not use > it. > > This isn't meant to be a slam on you or the others that have tried to > use $(eval) and been tripped up by how it works. I think $(eval) was > not documented with enough warnings about how non-intuitive it is, so > that it looks like a simple way for people to write more 'procedural' > makefile. In my experience, most users are slightly uncomfortable > with make's declarative operation, so the option to write a makefile > as if it was a procedural language is seductive. The problem is that > $(eval) was designed for the complex cases, where double expansion is > critical, and not for the simple cases, where double expansion is a > trap to drive users insane. > > > Perhaps you get all the above and my mention of > "before/during/afterwards" was all it took for you to see how to solve > your problem. That good, but I strongly suggest you reconsider your > use of $(eval) and whether it's actually necessary or just an attempt > to jam make into a different paradigm of expression. > > Similarly, I suggest to the GNU make maintainers to think *real hard* > about what they can do to ease the support burden that has been > created by $(eval) being freely used by people that think it simpler > than it is, perhaps starting with a pile of warnings and cookbook > examples in the info pages...but I'll leave that to someone who > actually likes $(eval). > > </soapbox> > > > Philip Guenther > > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/disclaimer/email.html > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/help-make/attachments/20090317/e4c7f249/attachment.html > > ------------------------------ > > _______________________________________________ > Help-make mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/help-make > > > End of Help-make Digest, Vol 76, Issue 8 > **************************************** >
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
