From MAILER-DAEMON Fri Aug 02 15:16:25 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V5Kpt-000808-Hp for mharc-help-make@gnu.org; Fri, 02 Aug 2013 15:16:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Kpe-0007xw-5t for help-make@gnu.org; Fri, 02 Aug 2013 15:16:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5KpV-0006JE-JL for help-make@gnu.org; Fri, 02 Aug 2013 15:16:10 -0400 Received: from nskntmtas03p.mx.bigpond.com ([61.9.168.143]:36448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5KpU-0006IK-OJ for help-make@gnu.org; Fri, 02 Aug 2013 15:16:01 -0400 Received: from nskntcmgw09p ([61.9.169.169]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20130802191555.LFYE1983.nskntmtas03p.mx.bigpond.com@nskntcmgw09p> for ; Fri, 2 Aug 2013 19:15:55 +0000 Received: from [192.168.0.2] ([60.226.40.101]) by nskntcmgw09p with BigPond Outbound id 7vFv1m0072AxJNs01vFvYy; Fri, 02 Aug 2013 19:15:55 +0000 X-Authority-Analysis: v=2.0 cv=APSpfbFe c=1 sm=1 a=DEuaAaWJphCBf5EW8FfZWA==:17 a=mhBnyhzaI_IA:10 a=Sv2sojjTAAAA:8 a=00kqJNuwAnsA:10 a=lsH2M2yZlmHlUIYsT7wA:9 a=pILNOxqGKmIA:10 a=6AVFGbLaYG4QxT3O:21 a=7WQLQ9eg9JN-J1w2:21 a=fx4T_Uvtxw20JPMaWGIA:9 a=_W_S_7VecoQA:10 a=IWYSS1xvTQrhijZO:21 a=DEuaAaWJphCBf5EW8FfZWA==:117 From: Richard McLean Subject: question on old style phoney targets Message-Id: <91D2E7CC-DD12-4AB2-9F2E-9DF9B74A5AA4@bigpond.net.au> Date: Sat, 3 Aug 2013 05:15:57 +1000 To: "help-make@gnu.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 61.9.168.143 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 19:16:24 -0000 Hello, I'm pretty new to GNU Make and am just trying to get a few things = straight in my head so please bear with me if these questions sound a = bit "basic"... I've read the Make Manual, and the O'Reilly book, as well as several = other references I have found. I'm trying to clarify some things about "old style phony target syntax", = mainly to give me a better understanding as to what's actually going on. I concede that using the .PHONY directive is the best way to go in a = modern GNU makefile, so please don't suggest I just do that, as that's = not really the aim of my question. Consider the makefile code : clean: -rm -f $(objects) Assuming that "clean" does NOT exist as a filename, then my = understanding is that "clean" will always be regarded as out-of-date, = and "make clean" will always result in the recipe being run. If "clean" does exist as a file, then the recipe will never be run, as = without any prerequisites, the mere existence of the file will be enough = for make to believe it is up-to-date. Of course, specifying the clean target as .PHONY, assures the same = outcome even if there does exist a file named clean : .PHONY: clean clean: -rm -f $(objects) And since this causes make to skip any implicit rule search to possibly = make the "clean" file from some other file, this code is more efficient. In some older references and also in several sections of the make = manual, an older style of phony target syntax is given, using the = "FORCE" target : clean: FORCE -rm -f $(objects) FORCE: My understanding here is that since "clean" and "FORCE" do not exist as = filenames, make will always consider them out-of-date. Issuing "make FORCE" on the command line will cause the makefile to be = read and parsed, the DAG built, the target (FORCE) and all it's = pre-requisites checked for existence/out-of-dateness. In this case, as the file "FORCE" doesn't exist, the end result will be = that the FORCE recipe (no recipe) will be executed and will result in a = no-op (assuming the parsing of the makefile has no side effects). In addition, running "make clean" will force the clean recipe to be = executed, even if "clean" exists as a filename, as the out-of-date FORCE = target is a normal (non-order-only) prerequisite of "clean". I'm not completely sure what is being achieved here, over and above my = first example with just the clean target ? In some ways we are just adding another layer of files that aren't = supposed to exist. I can see that if we used the FORCE target in many similar targets, then = this could minimise the number of files for which we must ensure = non-existence (ie. FORCE). Is that the main aim of this sort of code ? Also, would it be slightly better syntax to supply the FORCE target with = an empty recipe (trailing semicolon) to protect it from any match = anything implicit rules ? clean: FORCE -rm -f $(objects) FORCE: ; (since we now must ensure FORCE doesn't exist as a filename, we must = also make sure that make doesn't find a way to make it) In the Make Manual (Section 4.7 Rules without Recipes or Prerequisites) = it says : If a rule has no prerequisites or recipe, and the target of the rule is = a nonexistent file, then make imagines this target to have been updated = whenever its rule is run. This implies that all targets depending on = this one will always have their recipe run. I find the phrase "make imagines this target to have been updated = whenever its rule is run" a bit confusing for some reason. So is it better to supply the FORCE target with no recipe or an empty = recipe ? Also, as a completely unrelated question.... Can the "|" (vertical bar) operator and order-only-prerequisites play = any roles in pattern rules, or are they strictly related to explicit = rules ? In other words, can a pattern rule include order-only pre-requisites ? I cannot immediately see a reason why they should, but I'm just trying = to see what's acceptable syntax. Cheers and Thanks in Advance Richard P.S. please point out any errors in my summary of what I think is going = on - if my logic is flawed I would like to know about it <<<<<>>>>> 3.6 Overriding Part of Another Makefile Sometimes it is useful to have a makefile that is mostly just like = another makefile. You can often use the =91include=92 directive to = include one in the other, and add more targets or variable definitions. = However, it is illegal for two makefiles to give different recipes for = the same target. But there is another way. In the containing makefile (the one that wants to include the other), = you can use a match-anything pattern rule to say that to remake any = target that cannot be made from the information in the containing = makefile, make should look in another makefile. See Pattern Rules, for = more information on pattern rules. For example, if you have a makefile called Makefile that says how to = make the target =91foo=92 (and other targets), you can write a makefile = called GNUmakefile that contains: foo: frobnicate > foo =20 %: force @$(MAKE) -f Makefile $@ force: ; If you say =91make foo=92, make will find GNUmakefile, read it, and see = that to make foo, it needs to run the recipe =91frobnicate > foo=92. If = you say =91make bar=92, make will find no way to make bar in = GNUmakefile, so it will use the recipe from the pattern rule: =91make -f = Makefile bar=92. If Makefile provides a rule for updating bar, make will = apply the rule. And likewise for any other target that GNUmakefile does = not say how to make. The way this works is that the pattern rule has a pattern of just =91%=92,= so it matches any target whatever. The rule specifies a prerequisite = force, to guarantee that the recipe will be run even if the target file = already exists. We give the force target an empty recipe to prevent make = from searching for an implicit rule to build it=97otherwise it would = apply the same match-anything rule to force itself and create a = prerequisite loop! 4.6 Phony Targets A phony target is one that is not really the name of a file; rather it = is just a name for a recipe to be executed when you make an explicit = request. There are two reasons to use a phony target: to avoid a = conflict with a file of the same name, and to improve performance. If you write a rule whose recipe will not create the target file, the = recipe will be executed every time the target comes up for remaking. = Here is an example: clean: rm *.o temp Because the rm command does not create a file named clean, probably no = such file will ever exist. Therefore, the rm command will be executed = every time you say =91make clean=92. The phony target will cease to work = if anything ever does create a file named clean in this directory. Since = it has no prerequisites, the file clean would inevitably be considered = up to date, and its recipe would not be executed. To avoid this problem, = you can explicitly declare the target to be phony, using the special = target .PHONY (seeSpecial Built-in Target Names) as follows: .PHONY : clean Once this is done, =91make clean=92 will run the recipe regardless of = whether there is a file named clean. Since it knows that phony targets do not name actual files that could be = remade from other files, make skips the implicit rule search for phony = targets (see Implicit Rules). This is why declaring a target phony is = good for performance, even if you are not worried about the actual file = existing. Thus, you first write the line that states that clean is a phony target, = then you write the rule, like this: .PHONY: clean clean: rm *.o temp Another example of the usefulness of phony targets is in conjunction = with recursive invocations of make (for more information, see Recursive = Use of make). In this case the makefile will often contain a variable = which lists a number of subdirectories to be built. One way to handle = this is with one rule whose recipe is a shell loop over the = subdirectories, like this: SUBDIRS =3D foo bar baz =20 subdirs: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir; \ done There are problems with this method, however. First, any error detected = in a submake is ignored by this rule, so it will continue to build the = rest of the directories even when one fails. This can be overcome by = adding shell commands to note the error and exit, but then it will do so = even if make is invoked with the -k option, which is unfortunate. = Second, and perhaps more importantly, you cannot take advantage of = make's ability to build targets in parallel (see Parallel Execution), = since there is only one rule. By declaring the subdirectories as phony targets (you must do this as = the subdirectory obviously always exists; otherwise it won't be built) = you can remove these problems: SUBDIRS =3D foo bar baz =20 .PHONY: subdirs $(SUBDIRS) =20 subdirs: $(SUBDIRS) =20 $(SUBDIRS): $(MAKE) -C $@ =20 foo: baz Here we've also declared that the foo subdirectory cannot be built until = after the baz subdirectory is complete; this kind of relationship = declaration is particularly important when attempting parallel builds. A phony target should not be a prerequisite of a real target file; if it = is, its recipe will be run every time make goes to update that file. As = long as a phony target is never a prerequisite of a real target, the = phony target recipe will be executed only when the phony target is a = specified goal (see Arguments to Specify the Goals). Phony targets can have prerequisites. When one directory contains = multiple programs, it is most convenient to describe all of the programs = in one makefile ./Makefile. Since the target remade by default will be = the first one in the makefile, it is common to make this a phony target = named =91all=92 and give it, as prerequisites, all the individual = programs. For example: all : prog1 prog2 prog3 .PHONY : all =20 prog1 : prog1.o utils.o cc -o prog1 prog1.o utils.o =20 prog2 : prog2.o cc -o prog2 prog2.o =20 prog3 : prog3.o sort.o utils.o cc -o prog3 prog3.o sort.o utils.o Now you can say just =91make=92 to remake all three programs, or specify = as arguments the ones to remake (as in =91make prog1 prog3=92). = Phoniness is not inherited: the prerequisites of a phony target are not = themselves phony, unless explicitly declared to be so. When one phony target is a prerequisite of another, it serves as a = subroutine of the other. For example, here =91make cleanall=92 will = delete the object files, the difference files, and the file program: .PHONY: cleanall cleanobj cleandiff =20 cleanall : cleanobj cleandiff rm program =20 cleanobj : rm *.o =20 cleandiff : rm *.diff 4.7 Rules without Recipes or Prerequisites If a rule has no prerequisites or recipe, and the target of the rule is = a nonexistent file, then make imagines this target to have been updated = whenever its rule is run. This implies that all targets depending on = this one will always have their recipe run. An example will illustrate this: clean: FORCE rm $(objects) FORCE: Here the target =91FORCE=92 satisfies the special conditions, so the = target clean that depends on it is forced to run its recipe. There is = nothing special about the name =91FORCE=92, but that is one name = commonly used this way. As you can see, using =91FORCE=92 this way has the same results as using = =91.PHONY: clean=92. Using =91.PHONY=92 is more explicit and more efficient. However, other = versions of make do not support =91.PHONY=92; thus =91FORCE=92 appears = in many makefiles. See Phony Targets. 5.9 Using Empty Recipes It is sometimes useful to define recipes which do nothing. This is done = simply by giving a recipe that consists of nothing but whitespace. For = example: target: ; defines an empty recipe for target. You could also use a line beginning = with a recipe prefix character to define an empty recipe, but this would = be confusing because such a line looks empty. You may be wondering why you would want to define a recipe that does = nothing. The only reason this is useful is to prevent a target from = getting implicit recipes (from implicit rules or the .DEFAULT special = target; see Implicit Rules and see Defining Last-Resort Default Rules). You may be inclined to define empty recipes for targets that are not = actual files, but only exist so that their prerequisites can be remade. = However, this is not the best way to do that, because the prerequisites = may not be remade properly if the target file actually does exist. See = Phony Targets, for a better way to do this. From MAILER-DAEMON Fri Aug 02 19:52:54 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V5P9R-00076b-VK for mharc-help-make@gnu.org; Fri, 02 Aug 2013 19:52:53 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56013) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5P9K-00076G-E3 for help-make@gnu.org; Fri, 02 Aug 2013 19:52:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5P9D-0003yN-Nn for help-make@gnu.org; Fri, 02 Aug 2013 19:52:46 -0400 Received: from nschwmtas04p.mx.bigpond.com ([61.9.189.146]:34294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5P9C-0003y5-UI for help-make@gnu.org; Fri, 02 Aug 2013 19:52:39 -0400 Received: from nschwcmgw06p ([61.9.190.166]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20130802235235.TYTR2030.nschwmtas04p.mx.bigpond.com@nschwcmgw06p> for ; Fri, 2 Aug 2013 23:52:35 +0000 Received: from [10.92.118.239] ([1.128.249.192]) by nschwcmgw06p with BigPond Outbound id 7zsa1m00a49omrl01zsaEW; Fri, 02 Aug 2013 23:52:35 +0000 X-Authority-Analysis: v=2.0 cv=dewCLAre c=1 sm=1 a=i50SVuzLGyY0kuq9zOHCwQ==:17 a=7bV3xBYFuvcA:10 a=Sv2sojjTAAAA:8 a=hqk1VELjwrgA:10 a=mDV3o1hIAAAA:8 a=TKwV1as9bMwrovtyUtMA:9 a=pILNOxqGKmIA:10 a=ii61gXl28gQA:10 a=4gOSLXXe4MYrv6zf:21 a=r1pg6yjHtvrNxDrB:21 a=_W_S_7VecoQA:10 a=j5JGDCPIwBV1NkSn:21 a=i50SVuzLGyY0kuq9zOHCwQ==:117 From: Richard McLean Subject: old style phoney target syntax (part 2) Message-Id: <745FB575-89F8-4AB0-A355-59ADAD20BE54@bigpond.net.au> Date: Sat, 3 Aug 2013 09:52:35 +1000 To: "help-make@gnu.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 61.9.189.146 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 23:52:53 -0000 Further to my last question (see below)... Thinking about it a bit more, I think the phrase "make imagines this = target to have been updated whenever its rule is run" (Make Manual = Section 4.7 Rules without Recipes or Prerequisites - included below) may = be another way of saying that when a target has no prerequisites and no = recipe, then make does NOT perform a search for an implicit rule to = build the target. If that is the case then then the following 3 code snippets would be = exactly (functionally) equivalent : clean: FORCE -rm -f $(objects) FORCE: and=20 clean: FORCE -rm -f $(objects) FORCE: ; and .PHONY: clean clean: -rm -f $(objects) (note semi-colon denoting empty recipe for the FORCE target in the = second example) Am I correct in this interpretation ? Perhaps the 3rd example is a little more clear, and the currently = recommended way to go, but is there any functional difference between = the 3 examples ? As far as I can see, if the "make clean" command is issued, whether or = not the files "clean" or "FORCE" exist, the clean recipe will be run - = is that correct ? And any implicit rule that would potentially build a file called "clean" = or "FORCE" would not be actioned.... right ? Also, I'm still after an answer to the second unrelated question... Can the "|" (vertical bar) operator and order-only-prerequisites play = any roles in pattern rules, or are they strictly related to explicit = rules ? In other words, can a pattern rule include order-only pre-requisites ? I cannot immediately see a reason why they should, but I'm just trying = to see what's acceptable syntax. Cheers Richard <<<<>>>> Hello, I'm pretty new to GNU Make and am just trying to get a few things = straight in my head so please bear with me if these questions sound a = bit "basic"... I've read the Make Manual, and the O'Reilly book, as well as several = other references I have found. I'm trying to clarify some things about "old style phony target syntax", = mainly to give me a better understanding as to what's actually going on. I concede that using the .PHONY directive is the best way to go in a = modern GNU makefile, so please don't suggest I just do that, as that's = not really the aim of my question. Consider the makefile code : clean: -rm -f $(objects) Assuming that "clean" does NOT exist as a filename, then my = understanding is that "clean" will always be regarded as out-of-date, = and "make clean" will always result in the recipe being run. If "clean" does exist as a file, then the recipe will never be run, as = without any prerequisites, the mere existence of the file will be enough = for make to believe it is up-to-date. Of course, specifying the clean target as .PHONY, assures the same = outcome even if there does exist a file named clean : .PHONY: clean clean: -rm -f $(objects) And since this causes make to skip any implicit rule search to possibly = make the "clean" file from some other file, this code is more efficient. In some older references and also in several sections of the make = manual, an older style of phony target syntax is given, using the = "FORCE" target : clean: FORCE -rm -f $(objects) FORCE: My understanding here is that since "clean" and "FORCE" do not exist as = filenames, make will always consider them out-of-date. Issuing "make FORCE" on the command line will cause the makefile to be = read and parsed, the DAG built, the target (FORCE) and all it's = pre-requisites checked for existence/out-of-dateness. In this case, as the file "FORCE" doesn't exist, the end result will be = that the FORCE recipe (no recipe) will be executed and will result in a = no-op (assuming the parsing of the makefile has no side effects). In addition, running "make clean" will force the clean recipe to be = executed, even if "clean" exists as a filename, as the out-of-date FORCE = target is a normal (non-order-only) prerequisite of "clean". I'm not completely sure what is being achieved here, over and above my = first example with just the clean target ? In some ways we are just adding another layer of files that aren't = supposed to exist. I can see that if we used the FORCE target in many similar targets, then = this could minimise the number of files for which we must ensure = non-existence (ie. FORCE). Is that the main aim of this sort of code ? Also, would it be slightly better syntax to supply the FORCE target with = an empty recipe (trailing semicolon) to protect it from any match = anything implicit rules ? clean: FORCE -rm -f $(objects) FORCE: ; (since we now must ensure FORCE doesn't exist as a filename, we must = also make sure that make doesn't find a way to make it) In the Make Manual (Section 4.7 Rules without Recipes or Prerequisites) = it says : If a rule has no prerequisites or recipe, and the target of the rule is = a nonexistent file, then make imagines this target to have been updated = whenever its rule is run. This implies that all targets depending on = this one will always have their recipe run. I find the phrase "make imagines this target to have been updated = whenever its rule is run" a bit confusing for some reason. So is it better to supply the FORCE target with no recipe or an empty = recipe ? Also, as a completely unrelated question.... Can the "|" (vertical bar) operator and order-only-prerequisites play = any roles in pattern rules, or are they strictly related to explicit = rules ? In other words, can a pattern rule include order-only pre-requisites ? I cannot immediately see a reason why they should, but I'm just trying = to see what's acceptable syntax. Cheers and Thanks in Advance Richard P.S. please point out any errors in my summary of what I think is going = on - if my logic is flawed I would like to know about it <<<<<>>>>> 3.6 Overriding Part of Another Makefile Sometimes it is useful to have a makefile that is mostly just like = another makefile. You can often use the =91include=92 directive to = include one in the other, and add more targets or variable definitions. = However, it is illegal for two makefiles to give different recipes for = the same target. But there is another way. In the containing makefile (the one that wants to include the other), = you can use a match-anything pattern rule to say that to remake any = target that cannot be made from the information in the containing = makefile, make should look in another makefile. See Pattern Rules, for = more information on pattern rules. For example, if you have a makefile called Makefile that says how to = make the target =91foo=92 (and other targets), you can write a makefile = called GNUmakefile that contains: foo: frobnicate > foo %: force @$(MAKE) -f Makefile $@ force: ; If you say =91make foo=92, make will find GNUmakefile, read it, and see = that to make foo, it needs to run the recipe =91frobnicate > foo=92. If = you say =91make bar=92, make will find no way to make bar in = GNUmakefile, so it will use the recipe from the pattern rule: =91make -f = Makefile bar=92. If Makefile provides a rule for updating bar, make will = apply the rule. And likewise for any other target that GNUmakefile does = not say how to make. The way this works is that the pattern rule has a pattern of just =91%=92,= so it matches any target whatever. The rule specifies a prerequisite = force, to guarantee that the recipe will be run even if the target file = already exists. We give the force target an empty recipe to prevent make = from searching for an implicit rule to build it=97otherwise it would = apply the same match-anything rule to force itself and create a = prerequisite loop! 4.6 Phony Targets A phony target is one that is not really the name of a file; rather it = is just a name for a recipe to be executed when you make an explicit = request. There are two reasons to use a phony target: to avoid a = conflict with a file of the same name, and to improve performance. If you write a rule whose recipe will not create the target file, the = recipe will be executed every time the target comes up for remaking. = Here is an example: clean: rm *.o temp Because the rm command does not create a file named clean, probably no = such file will ever exist. Therefore, the rm command will be executed = every time you say =91make clean=92. The phony target will cease to work = if anything ever does create a file named clean in this directory. Since = it has no prerequisites, the file clean would inevitably be considered = up to date, and its recipe would not be executed. To avoid this problem, = you can explicitly declare the target to be phony, using the special = target .PHONY (seeSpecial Built-in Target Names) as follows: .PHONY : clean Once this is done, =91make clean=92 will run the recipe regardless of = whether there is a file named clean. Since it knows that phony targets do not name actual files that could be = remade from other files, make skips the implicit rule search for phony = targets (see Implicit Rules). This is why declaring a target phony is = good for performance, even if you are not worried about the actual file = existing. Thus, you first write the line that states that clean is a phony target, = then you write the rule, like this: .PHONY: clean clean: rm *.o temp Another example of the usefulness of phony targets is in conjunction = with recursive invocations of make (for more information, see Recursive = Use of make). In this case the makefile will often contain a variable = which lists a number of subdirectories to be built. One way to handle = this is with one rule whose recipe is a shell loop over the = subdirectories, like this: SUBDIRS =3D foo bar baz subdirs: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir; \ done There are problems with this method, however. First, any error detected = in a submake is ignored by this rule, so it will continue to build the = rest of the directories even when one fails. This can be overcome by = adding shell commands to note the error and exit, but then it will do so = even if make is invoked with the -k option, which is unfortunate. = Second, and perhaps more importantly, you cannot take advantage of = make's ability to build targets in parallel (see Parallel Execution), = since there is only one rule. By declaring the subdirectories as phony targets (you must do this as = the subdirectory obviously always exists; otherwise it won't be built) = you can remove these problems: SUBDIRS =3D foo bar baz .PHONY: subdirs $(SUBDIRS) subdirs: $(SUBDIRS) $(SUBDIRS): $(MAKE) -C $@ foo: baz Here we've also declared that the foo subdirectory cannot be built until = after the baz subdirectory is complete; this kind of relationship = declaration is particularly important when attempting parallel builds. A phony target should not be a prerequisite of a real target file; if it = is, its recipe will be run every time make goes to update that file. As = long as a phony target is never a prerequisite of a real target, the = phony target recipe will be executed only when the phony target is a = specified goal (see Arguments to Specify the Goals). Phony targets can have prerequisites. When one directory contains = multiple programs, it is most convenient to describe all of the programs = in one makefile ./Makefile. Since the target remade by default will be = the first one in the makefile, it is common to make this a phony target = named =91all=92 and give it, as prerequisites, all the individual = programs. For example: all : prog1 prog2 prog3 .PHONY : all prog1 : prog1.o utils.o cc -o prog1 prog1.o utils.o prog2 : prog2.o cc -o prog2 prog2.o prog3 : prog3.o sort.o utils.o cc -o prog3 prog3.o sort.o utils.o Now you can say just =91make=92 to remake all three programs, or specify = as arguments the ones to remake (as in =91make prog1 prog3=92). = Phoniness is not inherited: the prerequisites of a phony target are not = themselves phony, unless explicitly declared to be so. When one phony target is a prerequisite of another, it serves as a = subroutine of the other. For example, here =91make cleanall=92 will = delete the object files, the difference files, and the file program: .PHONY: cleanall cleanobj cleandiff cleanall : cleanobj cleandiff rm program cleanobj : rm *.o cleandiff : rm *.diff 4.7 Rules without Recipes or Prerequisites If a rule has no prerequisites or recipe, and the target of the rule is = a nonexistent file, then make imagines this target to have been updated = whenever its rule is run. This implies that all targets depending on = this one will always have their recipe run. An example will illustrate this: clean: FORCE rm $(objects) FORCE: Here the target =91FORCE=92 satisfies the special conditions, so the = target clean that depends on it is forced to run its recipe. There is = nothing special about the name =91FORCE=92, but that is one name = commonly used this way. As you can see, using =91FORCE=92 this way has the same results as using = =91.PHONY: clean=92. Using =91.PHONY=92 is more explicit and more efficient. However, other = versions of make do not support =91.PHONY=92; thus =91FORCE=92 appears = in many makefiles. See Phony Targets. 5.9 Using Empty Recipes It is sometimes useful to define recipes which do nothing. This is done = simply by giving a recipe that consists of nothing but whitespace. For = example: target: ; defines an empty recipe for target. You could also use a line beginning = with a recipe prefix character to define an empty recipe, but this would = be confusing because such a line looks empty. You may be wondering why you would want to define a recipe that does = nothing. The only reason this is useful is to prevent a target from = getting implicit recipes (from implicit rules or the .DEFAULT special = target; see Implicit Rules and see Defining Last-Resort Default Rules). You may be inclined to define empty recipes for targets that are not = actual files, but only exist so that their prerequisites can be remade. = However, this is not the best way to do that, because the prerequisites = may not be remade properly if the target file actually does exist. See = Phony Targets, for a better way to do this. _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make= From MAILER-DAEMON Sat Aug 03 07:40:56 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V5aCe-00046C-6L for mharc-help-make@gnu.org; Sat, 03 Aug 2013 07:40:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5aCW-00045s-Mu for help-make@gnu.org; Sat, 03 Aug 2013 07:40:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5aCQ-0002WC-00 for help-make@gnu.org; Sat, 03 Aug 2013 07:40:48 -0400 Received: from nschwmtas01p.mx.bigpond.com ([61.9.189.137]:33403) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5aCP-0002VQ-5a for help-make@gnu.org; Sat, 03 Aug 2013 07:40:41 -0400 Received: from nschwcmgw07p ([61.9.190.167]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20130803114037.PMYI26428.nschwmtas01p.mx.bigpond.com@nschwcmgw07p> for ; Sat, 3 Aug 2013 11:40:37 +0000 Received: from [192.168.0.2] ([60.226.40.101]) by nschwcmgw07p with BigPond Outbound id 8Bgc1m00i2AxJNs01Bgcgc; Sat, 03 Aug 2013 11:40:37 +0000 X-Authority-Analysis: v=2.0 cv=BKIxXSsG c=1 sm=1 a=DEuaAaWJphCBf5EW8FfZWA==:17 a=1BHEVd2Qtf4A:10 a=Sv2sojjTAAAA:8 a=dpX63Vy54oMA:10 a=mDV3o1hIAAAA:8 a=TKwV1as9bMwrovtyUtMA:9 a=pILNOxqGKmIA:10 a=ii61gXl28gQA:10 a=L0G24cN0F6ZI8O4n:21 a=wNFd4B9_UsuJOssr:21 a=_W_S_7VecoQA:10 a=GHAATRDvh_rHNqDM:21 a=DEuaAaWJphCBf5EW8FfZWA==:117 From: Richard McLean Subject: old style phoney target syntax (small correction) Message-Id: <96A52052-8887-446D-933C-230A3E6D375E@bigpond.net.au> Date: Sat, 3 Aug 2013 21:40:38 +1000 To: "help-make@gnu.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 61.9.189.137 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 11:40:55 -0000 One small adjustment... In my last post, the sentence : "As far as I can see, if the "make clean" command is issued, whether or = not the files "clean" or "FORCE" exist, the clean recipe will be run - = is that correct ?"=20 should have read : "As far as I can see, if the "make clean" command is issued, whether or = not the file "clean" exists, the clean recipe will be run, as long as = the file "FORCE" does not exist - is that correct ?" So the las email should have read as follows : Further to my last question (see below)... Thinking about it a bit more, I think the phrase "make imagines this = target to have been updated whenever its rule is run" (Make Manual = Section 4.7 Rules without Recipes or Prerequisites - included below) may = be another way of saying that when a target has no prerequisites and no = recipe, then make does NOT perform a search for an implicit rule to = build the target. If that is the case then then the following 3 code snippets would be = exactly (functionally) equivalent : clean: FORCE -rm -f $(objects) FORCE: and=20 clean: FORCE -rm -f $(objects) FORCE: ; and .PHONY: clean clean: -rm -f $(objects) (note semi-colon denoting empty recipe for the FORCE target in the = second example) Am I correct in this interpretation ? Perhaps the 3rd example is a little more clear, and the currently = recommended way to go, but is there any functional difference between = the 3 examples ? As far as I can see, if the "make clean" command is issued, whether or = not the file "clean" exists, the clean recipe will be run as long as the = file "FORCE" does not exist - is that correct ? And any implicit rule that would potentially build a file called "clean" = or "FORCE" would not be actioned.... right ? Also, I'm still after an answer to the second unrelated question... Can the "|" (vertical bar) operator and order-only-prerequisites play = any roles in pattern rules, or are they strictly related to explicit = rules ? In other words, can a pattern rule include order-only pre-requisites ? I cannot immediately see a reason why they should, but I'm just trying = to see what's acceptable syntax. Cheers Richard <<<<>>>> Hello, I'm pretty new to GNU Make and am just trying to get a few things = straight in my head so please bear with me if these questions sound a = bit "basic"... I've read the Make Manual, and the O'Reilly book, as well as several = other references I have found. I'm trying to clarify some things about "old style phony target syntax", = mainly to give me a better understanding as to what's actually going on. I concede that using the .PHONY directive is the best way to go in a = modern GNU makefile, so please don't suggest I just do that, as that's = not really the aim of my question. Consider the makefile code : clean: -rm -f $(objects) Assuming that "clean" does NOT exist as a filename, then my = understanding is that "clean" will always be regarded as out-of-date, = and "make clean" will always result in the recipe being run. If "clean" does exist as a file, then the recipe will never be run, as = without any prerequisites, the mere existence of the file will be enough = for make to believe it is up-to-date. Of course, specifying the clean target as .PHONY, assures the same = outcome even if there does exist a file named clean : .PHONY: clean clean: -rm -f $(objects) And since this causes make to skip any implicit rule search to possibly = make the "clean" file from some other file, this code is more efficient. In some older references and also in several sections of the make = manual, an older style of phony target syntax is given, using the = "FORCE" target : clean: FORCE -rm -f $(objects) FORCE: My understanding here is that since "clean" and "FORCE" do not exist as = filenames, make will always consider them out-of-date. Issuing "make FORCE" on the command line will cause the makefile to be = read and parsed, the DAG built, the target (FORCE) and all it's = pre-requisites checked for existence/out-of-dateness. In this case, as the file "FORCE" doesn't exist, the end result will be = that the FORCE recipe (no recipe) will be executed and will result in a = no-op (assuming the parsing of the makefile has no side effects). In addition, running "make clean" will force the clean recipe to be = executed, even if "clean" exists as a filename, as the out-of-date FORCE = target is a normal (non-order-only) prerequisite of "clean". I'm not completely sure what is being achieved here, over and above my = first example with just the clean target ? In some ways we are just adding another layer of files that aren't = supposed to exist. I can see that if we used the FORCE target in many similar targets, then = this could minimise the number of files for which we must ensure = non-existence (ie. FORCE). Is that the main aim of this sort of code ? Also, would it be slightly better syntax to supply the FORCE target with = an empty recipe (trailing semicolon) to protect it from any match = anything implicit rules ? clean: FORCE -rm -f $(objects) FORCE: ; (since we now must ensure FORCE doesn't exist as a filename, we must = also make sure that make doesn't find a way to make it) In the Make Manual (Section 4.7 Rules without Recipes or Prerequisites) = it says : If a rule has no prerequisites or recipe, and the target of the rule is = a nonexistent file, then make imagines this target to have been updated = whenever its rule is run. This implies that all targets depending on = this one will always have their recipe run. I find the phrase "make imagines this target to have been updated = whenever its rule is run" a bit confusing for some reason. So is it better to supply the FORCE target with no recipe or an empty = recipe ? Also, as a completely unrelated question.... Can the "|" (vertical bar) operator and order-only-prerequisites play = any roles in pattern rules, or are they strictly related to explicit = rules ? In other words, can a pattern rule include order-only pre-requisites ? I cannot immediately see a reason why they should, but I'm just trying = to see what's acceptable syntax. Cheers and Thanks in Advance Richard P.S. please point out any errors in my summary of what I think is going = on - if my logic is flawed I would like to know about it <<<<<>>>>> 3.6 Overriding Part of Another Makefile Sometimes it is useful to have a makefile that is mostly just like = another makefile. You can often use the =91include=92 directive to = include one in the other, and add more targets or variable definitions. = However, it is illegal for two makefiles to give different recipes for = the same target. But there is another way. In the containing makefile (the one that wants to include the other), = you can use a match-anything pattern rule to say that to remake any = target that cannot be made from the information in the containing = makefile, make should look in another makefile. See Pattern Rules, for = more information on pattern rules. For example, if you have a makefile called Makefile that says how to = make the target =91foo=92 (and other targets), you can write a makefile = called GNUmakefile that contains: foo: frobnicate > foo %: force @$(MAKE) -f Makefile $@ force: ; If you say =91make foo=92, make will find GNUmakefile, read it, and see = that to make foo, it needs to run the recipe =91frobnicate > foo=92. If = you say =91make bar=92, make will find no way to make bar in = GNUmakefile, so it will use the recipe from the pattern rule: =91make -f = Makefile bar=92. If Makefile provides a rule for updating bar, make will = apply the rule. And likewise for any other target that GNUmakefile does = not say how to make. The way this works is that the pattern rule has a pattern of just =91%=92,= so it matches any target whatever. The rule specifies a prerequisite = force, to guarantee that the recipe will be run even if the target file = already exists. We give the force target an empty recipe to prevent make = from searching for an implicit rule to build it=97otherwise it would = apply the same match-anything rule to force itself and create a = prerequisite loop! 4.6 Phony Targets A phony target is one that is not really the name of a file; rather it = is just a name for a recipe to be executed when you make an explicit = request. There are two reasons to use a phony target: to avoid a = conflict with a file of the same name, and to improve performance. If you write a rule whose recipe will not create the target file, the = recipe will be executed every time the target comes up for remaking. = Here is an example: clean: rm *.o temp Because the rm command does not create a file named clean, probably no = such file will ever exist. Therefore, the rm command will be executed = every time you say =91make clean=92. The phony target will cease to work = if anything ever does create a file named clean in this directory. Since = it has no prerequisites, the file clean would inevitably be considered = up to date, and its recipe would not be executed. To avoid this problem, = you can explicitly declare the target to be phony, using the special = target .PHONY (seeSpecial Built-in Target Names) as follows: .PHONY : clean Once this is done, =91make clean=92 will run the recipe regardless of = whether there is a file named clean. Since it knows that phony targets do not name actual files that could be = remade from other files, make skips the implicit rule search for phony = targets (see Implicit Rules). This is why declaring a target phony is = good for performance, even if you are not worried about the actual file = existing. Thus, you first write the line that states that clean is a phony target, = then you write the rule, like this: .PHONY: clean clean: rm *.o temp Another example of the usefulness of phony targets is in conjunction = with recursive invocations of make (for more information, see Recursive = Use of make). In this case the makefile will often contain a variable = which lists a number of subdirectories to be built. One way to handle = this is with one rule whose recipe is a shell loop over the = subdirectories, like this: SUBDIRS =3D foo bar baz subdirs: for dir in $(SUBDIRS); do \ $(MAKE) -C $$dir; \ done There are problems with this method, however. First, any error detected = in a submake is ignored by this rule, so it will continue to build the = rest of the directories even when one fails. This can be overcome by = adding shell commands to note the error and exit, but then it will do so = even if make is invoked with the -k option, which is unfortunate. = Second, and perhaps more importantly, you cannot take advantage of = make's ability to build targets in parallel (see Parallel Execution), = since there is only one rule. By declaring the subdirectories as phony targets (you must do this as = the subdirectory obviously always exists; otherwise it won't be built) = you can remove these problems: SUBDIRS =3D foo bar baz .PHONY: subdirs $(SUBDIRS) subdirs: $(SUBDIRS) $(SUBDIRS): $(MAKE) -C $@ foo: baz Here we've also declared that the foo subdirectory cannot be built until = after the baz subdirectory is complete; this kind of relationship = declaration is particularly important when attempting parallel builds. A phony target should not be a prerequisite of a real target file; if it = is, its recipe will be run every time make goes to update that file. As = long as a phony target is never a prerequisite of a real target, the = phony target recipe will be executed only when the phony target is a = specified goal (see Arguments to Specify the Goals). Phony targets can have prerequisites. When one directory contains = multiple programs, it is most convenient to describe all of the programs = in one makefile ./Makefile. Since the target remade by default will be = the first one in the makefile, it is common to make this a phony target = named =91all=92 and give it, as prerequisites, all the individual = programs. For example: all : prog1 prog2 prog3 .PHONY : all prog1 : prog1.o utils.o cc -o prog1 prog1.o utils.o prog2 : prog2.o cc -o prog2 prog2.o prog3 : prog3.o sort.o utils.o cc -o prog3 prog3.o sort.o utils.o Now you can say just =91make=92 to remake all three programs, or specify = as arguments the ones to remake (as in =91make prog1 prog3=92). = Phoniness is not inherited: the prerequisites of a phony target are not = themselves phony, unless explicitly declared to be so. When one phony target is a prerequisite of another, it serves as a = subroutine of the other. For example, here =91make cleanall=92 will = delete the object files, the difference files, and the file program: .PHONY: cleanall cleanobj cleandiff cleanall : cleanobj cleandiff rm program cleanobj : rm *.o cleandiff : rm *.diff 4.7 Rules without Recipes or Prerequisites If a rule has no prerequisites or recipe, and the target of the rule is = a nonexistent file, then make imagines this target to have been updated = whenever its rule is run. This implies that all targets depending on = this one will always have their recipe run. An example will illustrate this: clean: FORCE rm $(objects) FORCE: Here the target =91FORCE=92 satisfies the special conditions, so the = target clean that depends on it is forced to run its recipe. There is = nothing special about the name =91FORCE=92, but that is one name = commonly used this way. As you can see, using =91FORCE=92 this way has the same results as using = =91.PHONY: clean=92. Using =91.PHONY=92 is more explicit and more efficient. However, other = versions of make do not support =91.PHONY=92; thus =91FORCE=92 appears = in many makefiles. See Phony Targets. 5.9 Using Empty Recipes It is sometimes useful to define recipes which do nothing. This is done = simply by giving a recipe that consists of nothing but whitespace. For = example: target: ; defines an empty recipe for target. You could also use a line beginning = with a recipe prefix character to define an empty recipe, but this would = be confusing because such a line looks empty. You may be wondering why you would want to define a recipe that does = nothing. The only reason this is useful is to prevent a target from = getting implicit recipes (from implicit rules or the .DEFAULT special = target; see Implicit Rules and see Defining Last-Resort Default Rules). You may be inclined to define empty recipes for targets that are not = actual files, but only exist so that their prerequisites can be remade. = However, this is not the best way to do that, because the prerequisites = may not be remade properly if the target file actually does exist. See = Phony Targets, for a better way to do this. _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make= From MAILER-DAEMON Mon Aug 12 19:11:44 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V91H6-0005Ul-Er for mharc-help-make@gnu.org; Mon, 12 Aug 2013 19:11:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8zmk-0000r4-7T for help-make@gnu.org; Mon, 12 Aug 2013 17:36:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V8zme-0001WB-4X for help-make@gnu.org; Mon, 12 Aug 2013 17:36:18 -0400 Received: from as-smtp3.itc.alstom.com ([159.245.16.38]:34519 helo=itc.alstom.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8zmd-0001Vy-II for help-make@gnu.org; Mon, 12 Aug 2013 17:36:12 -0400 Received: from ([10.3.9.4]) by as-smtp3.itc.alstom.com with ESMTP with TLS id 4T3MQH1.232487556; Mon, 12 Aug 2013 23:36:07 +0200 Received: from 041-DB3MPN1-092.041d.mgd.msft.net ([169.254.2.18]) by 041-DB3MMR1-004.041d.mgd.msft.net ([10.228.1.14]) with mapi id 14.03.0146.002; Mon, 12 Aug 2013 21:36:07 +0000 From: LANGLOIS Olivier PIS -EXT To: "help-make@gnu.org" Subject: Target-specific Variable Values problem Thread-Topic: Target-specific Variable Values problem Thread-Index: Ac6XoVnffd/71rGgRW+XouP4aZ/uSA== Date: Mon, 12 Aug 2013 21:36:05 +0000 Message-ID: <89F8E4011FD7234ABFE48744E300CBC206B32907@041-DB3MPN1-092.041d.mgd.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.90.50.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 159.245.16.38 X-Mailman-Approved-At: Mon, 12 Aug 2013 19:11:43 -0400 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 21:36:25 -0000 Hi, I have 2 problems with a Makefile that I have crafted. The first one is tha= t I'm doing this: # Would need to make those variable recursive if debug target redefine the = dir vars. OBJS =3D $(SRCS:%.cpp=3D%.o) DEPS =3D $(SRCS:%.cpp=3D$(DEPDIR)%.depends) CPPFLAGS =3D -DNDEBUG -DBASE_VERSION CXXFLAGS =3D -std=3Dgnu++11 -pthread -march=3Dnative -Wall -O3 LDFLAGS =3D -pthread -Lbase LIBS :=3D -lbase $(shell pkg-config --libs libxml-2.0) $(shell pkg-config -= -libs libcrypto) SUBDIR_TARG :=3D all .PHONY : clean all subdirs $(SUBDIRS) # 'all' is the default target because it is the target of the first declare= d target. all : $(TARGET) subdirs: $(SUBDIRS) # # Possible additions to the debug target # - Use different directories for storing intermediate files so they can # coexist with the release ones # - Change target name # debug : CFLAGS =3D -std=3Dgnu++11 -pthread -Wall -g -O0 debug : CXXFLAGS =3D -std=3Dgnu++11 -pthread -Wall -g -O0 debug : CPPFLAGS =3D -DTRLDEBUG debug : SUBDIR_TARG :=3D debug debug : all $(SUBDIRS): $(MAKE) -C $@ $(SUBDIR_TARG) $(TARGET) : $(SUBDIRS) $(OBJS) $(CXX) $(LDFLAGS) -o $@ $(OBJS) $(LIBS) $(DEPDIR) : mkdir $(DEPDIR) # pattern rules # SHELL switches: # e: to exit immediatly if gcc fails # c: The script to execute is provided as a string argument with the comman= d. # - $* expends to '%' from the rule (In make terminology, the stem). # - The sed script triple single quote is tricky to understand. It is not a= llowed in # shell scripting to have a single quote between 2 single quotes so what = is done instead # is to close the quote started from the first line, add an escaped singl= e quote # reopen the initial quote. # - 3rd line is for testing that the sed output file is not empty and delet= e it # otherwise. # - '!' is used as the sed command delimiter instead of the usual '/'. This= is because we expect # the '/' char to appear in directory component of the filenames. $(DEPDIR)%.depends: %.cpp $(DEPDIR) $(SHELL) -ec '$(CXX) -MM $(INCLUDES) $(CPPFLAGS) $(CXXFLAGS) $< \ | sed '\''s!\($*\)\.o[ :]*!\1.o $@ : !g'\'' > $@; \ [ -s $@ ] || rm -f $@' %.o: %.cpp $(CXX) $(CXXFLAGS) $(INCLUDES) $(CPPFLAGS) -c $< -o $*.o clean : -rm -rf $(DEPDIR) $(TARGET) *.o make -C base clean # rules defining dependencies and using commands defined in pattern rules a= re included here. -include $(DEPS) my debug specific variables are expanded correctly for the targets $(TARGET= ) and %.o but are ignored for $(DEPDIR)%.depends. This not a very big deal = but it could lead some inaccuracies if some headers files are conditionally= included based on some defines included in $(CPPFLAGS). I kinda understand that my problem is related to the 2 make read phases but= I do not know how reformulate my makefile to deal with it. My second problem is that I am trying to reuse my implicit rules for a seco= nd target ie: client_test : TARGET =3D client_test client_test : SRCS =3D ClientBase.cpp client.cpp clientfsm.cpp http_clientf= sm.cpp \ client_test.cpp This doesn't work at all. OBJS =3D $(SRCS:%.cpp=3D%.o) DEPS =3D $(SRCS:%.cpp=3D$(DEPDIR)%.depends) expansion do not consider at all the target specific values. prerequisite secondary expansion seems to be more what I should use but I a= m not sure this is applicable since OBJS variable is used also in the rule = recipe. Links to complex makefile examples and/or templates that contains stuff sim= ilar that I am trying to accomplished are welcome. Thank you for your time. ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may = be privileged. If you are not a named recipient, please notify the sender i= mmediately and do not disclose the contents to another person, use it for a= ny purpose or store or copy the information in any medium. From MAILER-DAEMON Tue Aug 13 11:15:30 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V9GJm-0000QR-8v for mharc-help-make@gnu.org; Tue, 13 Aug 2013 11:15:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9G76-00082j-Jy for help-make@gnu.org; Tue, 13 Aug 2013 11:02:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9G75-0007ov-9b for help-make@gnu.org; Tue, 13 Aug 2013 11:02:24 -0400 Received: from mail-oa0-x22e.google.com ([2607:f8b0:4003:c02::22e]:34100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9G75-0007oq-5D for help-make@gnu.org; Tue, 13 Aug 2013 11:02:23 -0400 Received: by mail-oa0-f46.google.com with SMTP id l10so11377477oag.5 for ; Tue, 13 Aug 2013 08:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fESXyNQNgnKVRQZlx58ZbvRLvaY+oE4zYmlNN8FDrX0=; b=WtKtIjqkbfCJFVUy5h5cl1jdDNTqzL/L277TESeGUHVOJJdTc6Bl57q58UZbFrLU0O wSvJ0uCGKw9TL+nFqiDTcibWqUDsMndM3i3C8W3SLsipk1TthVYa87cdyHLlYXRPL0hw D+4kDw6SaUoy05q3tORMcIhwilvAhEMZz2rYFBGXumDsGQnGU65+9v8OWCLD3HUteArM b3FOTjshmS7l5XV1If3yq3/dAArFNa50AKjqzRw8rtgqYduArLrf3k6nEeM5jlZ+fkht pJOHkOcuuD3oCYodBasYPNXzvuihN4UPPqICHsWTsUbmFbCUBzOH0iY4H1vSTwhDn8Rb ibwg== MIME-Version: 1.0 X-Received: by 10.60.179.84 with SMTP id de20mr1060476oec.40.1376406142428; Tue, 13 Aug 2013 08:02:22 -0700 (PDT) Received: by 10.182.121.168 with HTTP; Tue, 13 Aug 2013 08:02:22 -0700 (PDT) Date: Tue, 13 Aug 2013 17:02:22 +0200 Message-ID: Subject: goal argument to make in any automatic variable ? what is @[ $(origin $(*)) != 'undefined' ] && .. for ? From: andreas graeper To: help-make@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c02::22e X-Mailman-Approved-At: Tue, 13 Aug 2013 11:15:26 -0400 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:02:26 -0000 hi, i found in the end of a main-makefile target: xxx @[ "$(origin $(*))" != "undefined" ] && echo "$($(*))" `make -f that-makefile goal` is called from shell script i tried to call a test makefile with and without goal make and make and i thought i could find the goal in $0 or $1 .. . is there a automatic variable that tells me whether an explicit goal was given as argument. and what is $*. in which cases it can be != 'undefined' ( result from $(origin $(*)) ) thanks in advance andreas From MAILER-DAEMON Tue Aug 13 11:38:49 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V9GgL-0001D0-4g for mharc-help-make@gnu.org; Tue, 13 Aug 2013 11:38:49 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9GgB-0000zJ-IY for help-make@gnu.org; Tue, 13 Aug 2013 11:38:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9Gg2-00065j-Ad for help-make@gnu.org; Tue, 13 Aug 2013 11:38:39 -0400 Received: from oproxy14-pub.mail.unifiedlayer.com ([67.222.51.224]:50995) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1V9Gg2-000658-0S for help-make@gnu.org; Tue, 13 Aug 2013 11:38:30 -0400 Received: (qmail 3565 invoked by uid 0); 13 Aug 2013 15:37:53 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy14.unifiedlayer.com with SMTP; 13 Aug 2013 15:37:53 -0000 Received: from [76.24.208.92] (port=55818 helo=[192.168.1.103]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1V9GfQ-0006iK-T8; Tue, 13 Aug 2013 09:37:53 -0600 Message-ID: <1376408265.3964.103.camel@pdsmac> Subject: Re: goal argument to make in any automatic variable ? what is @[ $(origin $(*)) != 'undefined' ] && .. for ? From: Paul Smith To: andreas graeper Date: Tue, 13 Aug 2013 11:37:45 -0400 In-Reply-To: References: Organization: GNU's Not Unix! Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 76.24.208.92 authed with paul+mad-scientist.us} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 67.222.51.224 Cc: help-make@gnu.org X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: psmith@gnu.org List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:38:47 -0000 On Tue, 2013-08-13 at 17:02 +0200, andreas graeper wrote: > target: xxx > @[ "$(origin $(*))" != "undefined" ] && echo "$($(*))" > > `make -f that-makefile goal` is called from shell script > > i tried to call a test makefile with and without goal > > make > and > make > and i thought i could find the goal in $0 or $1 .. . is there a > automatic variable that tells me whether an explicit goal was given as > argument. No; automatic variables are values that are only relevant for a given target. "Whether there was an explicit goal given as a command line argument" is a global setting for the entire make invocation, so doesn't belong there. Look up the MAKECMDGOALS variable in the GNU make manual. > and what is $*. in which cases it can be != 'undefined' ( result from > $(origin $(*)) ) The meaning of $* can be found in the GNU make manual section on automatic variables. It means the part of the target which matches a pattern. Note it will be empty if there's no pattern or suffix that matches this target. However note that origin takes the NAME of a variable. So by passing it $* the code is checking to see if the variable with the NAME $* is defined or not. If it wanted to see if the variable "*" itself is defined or not, it would call $(origin *) So in your example, if $* is "target", then this checks to see if the variable $(target) is defined or not. From MAILER-DAEMON Wed Aug 14 11:10:19 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V9ciJ-000073-F5 for mharc-help-make@gnu.org; Wed, 14 Aug 2013 11:10:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9bzV-0002bh-Sr for help-make@gnu.org; Wed, 14 Aug 2013 10:24:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9bzL-0006G5-MQ for help-make@gnu.org; Wed, 14 Aug 2013 10:24:01 -0400 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:55306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9bzL-0006CE-Be for help-make@gnu.org; Wed, 14 Aug 2013 10:23:51 -0400 Received: by mail-wi0-f180.google.com with SMTP id f14so2016139wiw.7 for ; Wed, 14 Aug 2013 07:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neurosky.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=DK6JblM1vTIEVf59lBWxPTE9oODgdlAGr1pWsYteUqw=; b=QzN6jBvymyDJ2daHlzvYgDCaasBJk6qAS8dx7B9Spb/Uwai9181xCzWV/YKZ/e7js0 +nHJfsdlx5Mku0vetoqLTwwP0L2gnOaUHskhnyTUYqx8UOkQ4nLAjz8G7mdfbjUPrRUD 9aOvGMKt6gMj6k9ue1P7WjYbTvhVWl/5sqAxc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=DK6JblM1vTIEVf59lBWxPTE9oODgdlAGr1pWsYteUqw=; b=kcyKvM7T/jxhDN0R/ln2N04F+FBB0hqZgghTDKqTpMrnN9/GHfBTbXIqFWW3H2i3/n PrX3SDmXHE9J1xAokFtmaM485aTfRTwRIUotqkfEbSNc3Q/2ld9s1cBZjDWwf4LHlLt4 C1hoNdam1WBOf2JypPz8lZ0G4lYsL3q7gPcq7btM97ohS6f5n2qf3KmplSicHysEvBp0 CEyGAj+ky8Vi5q2iNngnx2RVsAqlnf1/6XZONq4+EPK2Gtf6BDxp5+uR0188toQjube1 QFBU+4nCV6ym8uWkhOQwyYS/NfiojkP7nbnX5/8P5QoYu8GocLCyFttqzwANaHj4ymwT +l3w== X-Gm-Message-State: ALoCoQm1sHnu/GLyGbQgUn39lLSDR3PgSH7kbOoe1DQKf2wN2KwZqgalIdh5CFtBFk6UzoI55Gve MIME-Version: 1.0 X-Received: by 10.180.13.43 with SMTP id e11mr2327366wic.21.1376490229905; Wed, 14 Aug 2013 07:23:49 -0700 (PDT) Received: by 10.194.158.135 with HTTP; Wed, 14 Aug 2013 07:23:49 -0700 (PDT) Date: Wed, 14 Aug 2013 22:23:49 +0800 Message-ID: Subject: From: Chear Huang To: bug-make@gnu.org, help-make@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::234 X-Mailman-Approved-At: Wed, 14 Aug 2013 11:10:17 -0400 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:24:06 -0000 Hi, i'm new developer for linux program , and first time use make,could you please send some sample of demonstrate to let me go start. Thanks Chear From MAILER-DAEMON Thu Aug 15 08:18:27 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V9wVX-0002ZC-8l for mharc-help-make@gnu.org; Thu, 15 Aug 2013 08:18:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9vlG-0003hO-Kd for help-make@gnu.org; Thu, 15 Aug 2013 07:30:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9vlA-0008BX-DT for help-make@gnu.org; Thu, 15 Aug 2013 07:30:38 -0400 Received: from nm28.bullet.mail.bf1.yahoo.com ([98.139.212.187]:31369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9vl9-0008BC-Tq for help-make@gnu.org; Thu, 15 Aug 2013 07:30:32 -0400 Received: from [98.139.215.142] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2013 11:30:30 -0000 Received: from [98.139.212.211] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2013 11:30:30 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 15 Aug 2013 11:30:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 671547.57894.bm@omp1020.mail.bf1.yahoo.com Received: (qmail 62500 invoked by uid 60001); 15 Aug 2013 11:30:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s1024; t=1376566230; bh=oy8pGHJGJydV/sAL4MWIrUL653wz61lelf0L2YTgyCA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=B69GgVDNKz4b/zuGiLsjPLabSHuc73otLJX4leavcP9bGKTxSOKO0TWrWN7DY4sgBSYw0IDnHvVTqoUxGy2I54uzxlhOfun7tIBOBGczYwYvoL5opYY4VVGGpsXs8LElXH+nClXOKv6ogzg9wBEqVlxD9cSo3hLetsgJrQy9h/I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=fGOKaVgT5MzQOXSNA6/9Si6KNSB5MWLW+Ra9pzJ7BSRVL6IuRxXz2PElwdUmyFPZetYzMdV4KZ1lW2NA3AE1nXWZDZhbpUgP9M9LYD7kkYeaDUKEgRW+7pDGvKGdemWd6ePX0jv2WXAQBPe/QtP9AC5dI3WE1AwqaNUGTqtB9yE=; X-YMail-OSG: sYsgykEVM1k4wmD4v1NMCzd0bEor1LLgI8XkTxnGPwQkZBg WhZueNPEd2i.BXaG4DeK3WyclhTa9_GND7AtNEwaakleIUQc9WOB.wU.TJjK jbDkTPer1VcfuhVNRqS__ovAHQIF8Dzpwl0SJ3un84_L16imbnbkML5l582J 7qa1TwmyKwKasMMkj7iRL2yxVjNH_jR5NnaidCArST2ZQaIggBOEV4B3yEDt tKqtNhOB0I.t8MFmZwsOp2nY1ejOkFzRTO19x0YItRf0T4i6Hruhf8DbVZgC QRqwZ8hw_rOvz5KZA3oof5Z2R3mctFW_SBYBd4IJXuNntVtljEnaSuh6gGj9 N1aoGnk2CSIEZdaPkGwI_xaL8tupVPFLArkDYS9EwumbSia.hCz89cJLdaoo YBoKAiUp5eM8FztS4efMyij5RsRSYUVLeuvV006542P6VX54nTBAHnM7hIGW KHUdNXIOgaIn7Yq.m0XUS4Y44yaVf.qRaTCN.5e1hOyjlXhKdIqNjJHqZGmp BL7SPE.w9GFbaK5DBrSEnRwcDCTXHwCNBEEuR.ULNPF7zStiCN6Cc8iW4aWx b8oTUsQIXag-- Received: from [14.139.128.15] by web161306.mail.bf1.yahoo.com via HTTP; Thu, 15 Aug 2013 04:30:30 PDT X-Rocket-MIMEInfo: 002.001, SGV5IHRoZXJlCgrCoMKgIEkganVzdCB3YW50ZWQgdG8ga25vdyBob3cgY2FuIEkgbW9kaWZ5IHRoZSBkZWZhdWx0IGJlaGF2aW91cih3aXRob3V0IHVzaW5nIGFueSBtYWtlZmlsZSkgb2YgdGhlIAoibWFrZSIgY29tbWFuZD8gCgpjdXJyZW50bHkgaWYgaSBpc3N1ZSAibWFrZSBmaWxlbmFtZSIgaXQgY29udmVydHMgaW50byA6wqAgCgoiY2MgLW8gZmlsZW5hbWUgZmlsZW5hbWUuYyIgCgpBbmQgSSB3YW50IGl0IAp0byBiZSByZXBsYWNlZCB3aXRoICJjbGFuZyAtZ2dkYiAtc3RkPWM5OSAtV2FsbCAtV2Vycm8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.154.571 Message-ID: <1376566230.51034.YahooMailNeo@web161306.mail.bf1.yahoo.com> Date: Thu, 15 Aug 2013 04:30:30 -0700 (PDT) From: Puneet Pahuja Subject: query To: "help-make@gnu.org" MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 98.139.212.187 X-Mailman-Approved-At: Thu, 15 Aug 2013 08:18:25 -0400 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Puneet Pahuja List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 11:30:46 -0000 Hey there=0A=0A=A0=A0 I just wanted to know how can I modify the default be= haviour(without using any makefile) of the =0A"make" command? =0A=0Acurrent= ly if i issue "make filename" it converts into :=A0 =0A=0A"cc -o filename f= ilename.c" =0A=0AAnd I want it =0Ato be replaced with "clang -ggdb -std=3Dc= 99 -Wall -Werror filename.c -lcrypt -lcs50 -lm -o filename"=0A=0A=0ARegards= =0APuneet Pahuja=0A From MAILER-DAEMON Thu Aug 15 08:23:06 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V9wa2-0004GS-BJ for mharc-help-make@gnu.org; Thu, 15 Aug 2013 08:23:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9wZs-0004G1-HQ for help-make@gnu.org; Thu, 15 Aug 2013 08:23:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9wZk-0002Nt-Ex for help-make@gnu.org; Thu, 15 Aug 2013 08:22:56 -0400 Received: from oproxy12-pub.mail.unifiedlayer.com ([50.87.16.10]:35607) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1V9wZk-0002Ng-7d for help-make@gnu.org; Thu, 15 Aug 2013 08:22:48 -0400 Received: (qmail 16347 invoked by uid 0); 15 Aug 2013 12:22:24 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy12.mail.unifiedlayer.com with SMTP; 15 Aug 2013 12:22:24 -0000 Received: from [146.115.71.23] (port=48801 helo=[172.31.1.206]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1V9wZL-0006og-Uj; Thu, 15 Aug 2013 06:22:24 -0600 Message-ID: <1376569343.2629.41.camel@homebase> Subject: Re: query From: Paul Smith To: Puneet Pahuja Date: Thu, 15 Aug 2013 08:22:23 -0400 In-Reply-To: <1376566230.51034.YahooMailNeo@web161306.mail.bf1.yahoo.com> References: <1376566230.51034.YahooMailNeo@web161306.mail.bf1.yahoo.com> Organization: GNU's Not UNIX! Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 146.115.71.23 authed with paul@mad-scientist.us} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 50.87.16.10 Cc: "help-make@gnu.org" X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: psmith@gnu.org List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 12:23:04 -0000 On Thu, 2013-08-15 at 04:30 -0700, Puneet Pahuja wrote: > I just wanted to know how can I modify the default behaviour(without > using any makefile) of the "make" command? > > currently if i issue "make filename" it converts into : > > "cc -o filename filename.c" > > And I want it to be replaced with "clang -ggdb -std=c99 -Wall -Werror > filename.c -lcrypt -lcs50 -lm -o filename" You can control all these things with variables on the command line: make filename CC=clang \ CFLAGS='-ggdb -std=c99 -Wall -Werror' \ LDLIBS='-lcrypt -lcs50 -lm' Other than that no, there's no way to do this unless you create a makefile and add those values to it. Or, of course, you could get the source code to GNU make and change the default values, compile it, then use that version of GNU make. Since you don't say WHY you want to do this it's hard to come up with acceptable alternatives. From MAILER-DAEMON Thu Aug 15 08:43:32 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V9wto-0007tW-U3 for mharc-help-make@gnu.org; Thu, 15 Aug 2013 08:43:32 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9wth-0007kb-O5 for help-make@gnu.org; Thu, 15 Aug 2013 08:43:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9wtb-0001md-Oc for help-make@gnu.org; Thu, 15 Aug 2013 08:43:25 -0400 Received: from mout.gmx.net ([212.227.15.15]:62199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9wtb-0001lC-Ep for help-make@gnu.org; Thu, 15 Aug 2013 08:43:19 -0400 Received: from Dago ([85.176.100.208]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LynHb-1WDVsA1jcN-0168vB for ; Thu, 15 Aug 2013 14:43:17 +0200 Date: Thu, 15 Aug 2013 14:42:31 +0200 From: Michael Ludwig To: help-make@gnu.org Subject: Re: Help installation REAP Message-ID: <20130815124231.GI5108@Dago> Mail-Followup-To: help-make@gnu.org References: <1373285030.6044.36.camel@homebase> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1373285030.6044.36.camel@homebase> User-Agent: Mutt/1.5.21+52 (c26dbc7021f4) (2011-07-01) X-Provags-ID: V03:K0:jiNUaO8Gp5bU6ZVcdu0JqqkrtOn9FlC1aNZSYEM6VOYWmjpBQGr QJs6YsMcabAph3qDOinUSLANyoTPU1qwdBq9BrFw26VKUu/CONkcyQgiLAFOYpKZZWs/F/Q VbFwcKMsL7BJCy7IczfS99M6Ki57DKbLBe9Za0kkHyMOc9yJk1c8TlVmDHG6pE7m5L+8LQV rELph1VFlfHS5u+Ld0HkQ== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.15 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 12:43:31 -0000 Paul Smith schrieb am 08.07.2013 um 08:03 (-0400): > On Mon, 2013-07-08 at 06:35 +0000, M.C. Medina Gomez wrote: > > /tmp/ccTpN0kH.o: In function `getkinship': > > REAP_SOURCE.c:(.text+0x3206): undefined reference to `sqrt' > > collect2: ld returned 1 exit status > > make: *** [REAP] Error 1 > Libraries should always come at the END of the link line; the > command-line switches to the compiler, unlike most typical UNIX > commands, are very order-dependent. See here for an example explaining the issue: Linker order - GCC - Stack Overflow http://stackoverflow.com/a/6717376 Also check the answers on that page by Johannes Schaub and casualcoder. Michael From MAILER-DAEMON Wed Aug 21 02:19:35 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VC1lX-0000Yv-GO for mharc-help-make@gnu.org; Wed, 21 Aug 2013 02:19:35 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBwrL-0007Tu-HY for help-make@gnu.org; Tue, 20 Aug 2013 21:05:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBwrJ-0004SB-2Y for help-make@gnu.org; Tue, 20 Aug 2013 21:05:15 -0400 Received: from mail-ve0-x22b.google.com ([2607:f8b0:400c:c01::22b]:42634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBwrI-0004Rv-Ut for help-make@gnu.org; Tue, 20 Aug 2013 21:05:12 -0400 Received: by mail-ve0-f171.google.com with SMTP id pa12so926844veb.16 for ; Tue, 20 Aug 2013 18:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+qUTgxux9baY+J3lYcPkJSu62uu32dxyNFmfmjUXW6U=; b=T01J3dP1XM34vcJ8mpw52ITygisuzfiMQ2Uid8J/BCG68ofIvGSxKPQG0Fps70HdRT XZOr91WrR56935z3Tnlp8Xagkv181Y18FbqWvXOOebnVH1IC5OdsGxpjodUMKABn1/YN OhlKjaGgFIy3vAgSyOG2lK1e58A1uTVuLAHJY0UbE5zw/IFTBfxtgE84q3Jt8p0WVVRa zTICIXfHZ2pDidUV3HJFnWo/65y6pWpBYvsVyGrRqiX38nAP0AVJfnzNOjWphvrTpZ+j QSato6krN/krIOj0QvSuFUMSegzGwo4wA1tC5P+Dhz4jH222O9c+OreiRD3bE45fMfrY ublA== MIME-Version: 1.0 X-Received: by 10.58.75.41 with SMTP id z9mr3757437vev.4.1377047111937; Tue, 20 Aug 2013 18:05:11 -0700 (PDT) Received: by 10.58.76.129 with HTTP; Tue, 20 Aug 2013 18:05:11 -0700 (PDT) Date: Wed, 21 Aug 2013 03:05:11 +0200 Message-ID: Subject: Prerequisites in subdirectories From: =?ISO-8859-1?Q?Ahmet_G=F6k=E7e?= To: help-make@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c01::22b X-Mailman-Approved-At: Wed, 21 Aug 2013 02:19:34 -0400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 01:05:18 -0000 Hello everybody, I use some tools which create outputs on subdirectories. If I want to use the created files in subsequent rules, I must run make for the second time that these prerequisites can be found. Example: second: first @ls $< first: | dir @touch dir/$@ dir: mkdir -p $@ VPATH=3Ddir clean:: $(RM) -r dir If I run make for the first time: mkdir -p dir touch dir/first ls first ls: cannot access first: No such file or directory .. and second time: ls dir/first dir/first .. voila! 1) Why does the make need two steps? 2) If it is a normal behavior, why did the make let the upmost rule run in the first run even the prerequisite 'first' didn't exist? (ls first) Kind Regards, G=F6k=E7e From MAILER-DAEMON Wed Aug 21 05:50:58 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VC546-0008GB-Fw for mharc-help-make@gnu.org; Wed, 21 Aug 2013 05:50:58 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC540-0008G1-8E for help-make@gnu.org; Wed, 21 Aug 2013 05:50:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VC53y-0001cN-Bh for help-make@gnu.org; Wed, 21 Aug 2013 05:50:52 -0400 Received: from mail-vc0-x230.google.com ([2607:f8b0:400c:c03::230]:55650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VC53y-0001c7-5V for help-make@gnu.org; Wed, 21 Aug 2013 05:50:50 -0400 Received: by mail-vc0-f176.google.com with SMTP id ha11so118433vcb.21 for ; Wed, 21 Aug 2013 02:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XfYRLLpqUBWXZEhMyTHApVWKp9KKTR50j7xM0Bpt+DI=; b=VDpuL/O0LbmEEaRMZPB0Euxl3F9A9IwuN3hlZQRNZ/zgGWjvxXOxmWtJmInWyk9dRL y9yn8EUBZxwJEnltN+gNAXiPHqnqDo4xQAplB0cx4RE6GVZihsmfgdHQucujJRXKMhDN p7+n53+OwwztOyO5nHQ6yjbXygtVUhJHVonsKPV7aiWWOrPu8NRxJPvbLXKdJCzKR6Yn fd+CWB1QUGcH9snsdr9t8jro5oyhCQl/0OuVYduaNFob14p+ZULPsXvlH+pG4nUu5zJt ZgCM+xuNE8VhutOKsWxIDakcfrsY4rAAWTXbxDS7rbcMgmLEIMEp9YqrBAEJwPep1mUk bOkw== MIME-Version: 1.0 X-Received: by 10.220.105.199 with SMTP id u7mr5575888vco.1.1377078649140; Wed, 21 Aug 2013 02:50:49 -0700 (PDT) Received: by 10.52.188.233 with HTTP; Wed, 21 Aug 2013 02:50:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Aug 2013 02:50:49 -0700 Message-ID: Subject: Re: Prerequisites in subdirectories From: Philip Guenther To: =?ISO-8859-1?Q?Ahmet_G=F6k=E7e?= X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c03::230 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: make-help mailing list X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 09:50:57 -0000 On Tue, Aug 20, 2013 at 6:05 PM, Ahmet G=F6k=E7e wrot= e: > I use some tools which create outputs on subdirectories. If I want to use > the created files in subsequent rules, I must run make for the second tim= e > that these prerequisites can be found. > > Example: > second: first > @ls $< > > first: | dir > @touch dir/$@ > To quote http://make.paulandlesley.org/rules.html Every non-.PHONY rule must update a file with the exact name of its target. Make sure every command script touches the file "$@"-- not "../$@", or "$(notdir $@)", but exactly $@. That way you and GNU make always agree. That rule in your makefile violates the above guidance and the odd results you're experiencing are *exactly* caused by it. Go read that page, as well as http://make.paulandlesley.org/vpath.html for thoughts on how to solve your overall problem. Philip Guenther From MAILER-DAEMON Thu Aug 29 19:00:46 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VFBCn-0003wz-Jm for mharc-help-make@gnu.org; Thu, 29 Aug 2013 19:00:46 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF4F0-0004v5-DM for help-make@gnu.org; Thu, 29 Aug 2013 11:34:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VF4Eu-0006tu-FB for help-make@gnu.org; Thu, 29 Aug 2013 11:34:34 -0400 Received: from mail.nottheoilrig.com ([50.16.249.74]:33651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF4Eu-0006tg-8h for help-make@gnu.org; Thu, 29 Aug 2013 11:34:28 -0400 Received: from mail.nottheoilrig.com (localhost [127.0.0.1]) by mail.nottheoilrig.com (Postfix) with ESMTP id A979E40BBB for ; Thu, 29 Aug 2013 15:34:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nottheoilrig.com; s=mail; t=1377790464; bh=/spRFtuzTvZAtEidPdL1iAHCwFp3plcGnnS+bqMEkmE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=EmxFfrOMHXk3peNU0hD6XN8BjjZZX2nTYhsUW+zejrodszHGcHgbT2dD5LdAUSk3e +oBilDOBq7lOwhp+JcUWUGJATVsmZVLN3TKx69yx5PN1V8TutZm3FInvDQeZ367wnR PLCeIUObuEJGZmoQqvHNmNFSPZV3GpJ/nZd+MWw8= Received: from [192.168.0.11] (S0106c8fb26402908.ek.shawcable.net [24.66.136.12]) by mail.nottheoilrig.com (Postfix) with ESMTPSA for ; Thu, 29 Aug 2013 15:34:24 +0000 (UTC) Message-ID: <521F6A00.5030705@nottheoilrig.com> Date: Thu, 29 Aug 2013 08:34:24 -0700 From: Jack Bates User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: help-make@gnu.org Subject: Output of one recipe in arguments to subsequent recipes? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 50.16.249.74 X-Mailman-Approved-At: Thu, 29 Aug 2013 19:00:43 -0400 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:34:41 -0000 Is there any way to use the standard output of one command (recipe) in arguments to subsequent recipes? How would you approach something like the following (which doesn't work): > school: > export HOST=$$(php /usr/share/cacti/cli/add_device.php \ > --description=school \ > --ip=172.23.0.1 \ > --template=1 | sed -n 's/Success - new device-id: (\([0-9]\+\))/\1/p') > > php /usr/share/cacti/cli/add_tree.php \ > --type=node \ > --node-type=host \ > --tree-id=$$DEFAULT_TREE \ > --host-id=$$HOST > > php /usr/share/cacti/cli/add_graphs.php \ > --graph-type=ds \ > --graph-template-id=$$TRAFFIC \ > --host-id=$$HOST \ > --snmp-query-id=$$INTERFACE_STATISTICS \ > --snmp-query-type-id=$$IN_OUT_BITS \ > --snmp-field=ifOperStatus \ > --snmp-value=Up I want to assign the standard output to the HOST variable and then use that in arguments to subsequent commands. I guess the above doesn't work because variables from one recipe aren't propagated to subsequent recipes, but is there any way to do it correctly? Thanks! From MAILER-DAEMON Thu Aug 29 19:48:33 2013 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VFBx2-0000EB-VQ for mharc-help-make@gnu.org; Thu, 29 Aug 2013 19:48:33 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFBwx-0008UV-AS for help-make@gnu.org; Thu, 29 Aug 2013 19:48:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VFBws-0005vr-P0 for help-make@gnu.org; Thu, 29 Aug 2013 19:48:27 -0400 Received: from smtp01.stowers.org ([12.201.176.61]:54778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VFBws-0005vb-IU for help-make@gnu.org; Thu, 29 Aug 2013 19:48:22 -0400 Received: from pps.filterd (smtp01.stowers.org [127.0.0.1]) by smtp01.stowers.org (8.14.5/8.14.5) with SMTP id r7TNm95U009575; Thu, 29 Aug 2013 18:48:21 -0500 Received: from mbsrv01.sgc.loc (mbsrv01.sgc.loc [10.0.52.150]) by smtp01.stowers.org with ESMTP id 1ejdq3g1vq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Aug 2013 18:48:21 -0500 Received: from MBSRV02.sgc.loc ([::1]) by MBSRV01.sgc.loc ([::1]) with mapi id 14.03.0158.001; Thu, 29 Aug 2013 18:48:21 -0500 From: "Cook, Malcolm" To: Jack Bates , "help-make@gnu.org" Subject: RE: Output of one recipe in arguments to subsequent recipes? Thread-Topic: Output of one recipe in arguments to subsequent recipes? Thread-Index: AQHOpQugXS2P/p4bVkq2cyNzzmzkh5ms2EtZ Date: Thu, 29 Aug 2013 23:48:19 +0000 Message-ID: References: <521F6A00.5030705@nottheoilrig.com> In-Reply-To: <521F6A00.5030705@nottheoilrig.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.24.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-29_09:2013-08-29, 2013-08-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308290146 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 12.201.176.61 X-BeenThere: help-make@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU implementation of make List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 23:48:31 -0000 by default, each of your three recipe lines is running in its own subshell.= =0A= =0A= thus the export in first line is not seen by subsequent lines.=0A= =0A= if you end each command with a semi-colon and a backslash followed by your = neline, then the three commands will execute in the same subshell.=0A= =0A= see:=0A= http://www.gnu.org/software/make/manual/html_node/Execution.html=0A= and=0A= http://www.gnu.org/software/make/manual/html_node/Splitting-Lines.html#Spli= tting-Lines=0A= =0A= you might prefer an "&&" instead of a ";" if you want to stop execution aft= er the first command that fails.=0A= =0A= =0A= ~ malcolm_cook@stowers.org=0A= =0A= ________________________________________=0A= From: help-make-bounces+mec=3Dstowers.org@gnu.org [help-make-bounces+mec=3D= stowers.org@gnu.org] on behalf of Jack Bates [k2r6ik@nottheoilrig.com]=0A= Sent: Thursday, August 29, 2013 10:34 AM=0A= To: help-make@gnu.org=0A= Subject: Output of one recipe in arguments to subsequent recipes?=0A= =0A= Is there any way to use the standard output of one command (recipe) in=0A= arguments to subsequent recipes? How would you approach something like=0A= the following (which doesn't work):=0A= =0A= > school:=0A= > export HOST=3D$$(php /usr/share/cacti/cli/add_device.php \=0A= > --description=3Dschool \=0A= > --ip=3D172.23.0.1 \=0A= > --template=3D1 | sed -n 's/Success - new device-id:=0A= (\([0-9]\+\))/\1/p')=0A= >=0A= > php /usr/share/cacti/cli/add_tree.php \=0A= > --type=3Dnode \=0A= > --node-type=3Dhost \=0A= > --tree-id=3D$$DEFAULT_TREE \=0A= > --host-id=3D$$HOST=0A= >=0A= > php /usr/share/cacti/cli/add_graphs.php \=0A= > --graph-type=3Dds \=0A= > --graph-template-id=3D$$TRAFFIC \=0A= > --host-id=3D$$HOST \=0A= > --snmp-query-id=3D$$INTERFACE_STATISTICS \=0A= > --snmp-query-type-id=3D$$IN_OUT_BITS \=0A= > --snmp-field=3DifOperStatus \=0A= > --snmp-value=3DUp=0A= =0A= I want to assign the standard output to the HOST variable and then use=0A= that in arguments to subsequent commands. I guess the above doesn't work=0A= because variables from one recipe aren't propagated to subsequent=0A= recipes, but is there any way to do it correctly?=0A= =0A= Thanks!=0A= =0A= _______________________________________________=0A= Help-make mailing list=0A= Help-make@gnu.org=0A= https://lists.gnu.org/mailman/listinfo/help-make=0A=