Looking at the GNU make manual, what exactly is the difference between an empty recipe and no recipe (for example see one instance in Rules without Recipes or Prerequisites)? More importantly, when should one use/avoid each of these two recipes?
In my current understanding, one should always use
target: ;
because sometimes an implicit rule could defeat one's purpose of no rule.
A given target can have only one recipe. If you declare an empty recipe then you've now given that target that recipe and it won't be searched for via implicit rules. Also if you try to give that same target another recipe, then make will complain.
"No recipe" just means you're adding more prerequisites to an existing target or, if you don't list prerequisites, you're just informing make that this is a target you're interested in. But you're not overriding any recipe lookup that make will do elsewhere.
It's definitely not true that one should always use one or the other: the one you use depends on what you're trying to achieve.
I don't know what you mean when you say defeat one's purpose of no rule so I can't respond to that... what are you trying to achieve when you say "no rule"?
Related
I have inherited a problematic Makefile.am that has been causing build issues. In this makefile, there are a couple instances where there are almost duplicate target rules. They are almost duplicate because the second one has one or two extra prerequisites. Here is an example:
target1 target2: prereq1 prereq2
ACTION
target1 target2: prereq1 prereq2 prereq3
ACTION
The action is identical, and target1 and target2 are identical. What is the consequence of this? Will both rules be executed?
To extend this question a bit, if prereq3 was auto generated during the make process, how would this play out? If make is run in parallel, could this cause big issues?
The action is identical, and target1 and target2 are identical. What
is the consequence of this? Will both rules be executed?
The consequence is that the makefiles generated based on this Makefile.am, which will include both rules verbatim, will fail to conform to the POSIX specifications for makefiles. POSIX forbids that more than one target rule provide a recipe for any given target.
If you happen to use GNU make to build, then instead of rejecting the makefile outright, it will use the last-given recipe for each target; all other target rules for each target will be treated as prerequisite-only rules, whether they provide a recipe or not. If you use a different make (which the Autotools expressly support), then results may differ. Relying on implementation-specific behavior such as this is very poor form in Autotools build systems.
Since the recipes are the same, the targets are the same, and the prerequisite list of the earlier rule is a subset of the prerequisite list of the later rule, I see no reason whatever to retain the earlier rule. Just delete it wholesale. No behavior will change under GNU make, and you will not have to worry about the behavior of other makes differing on account of this issue.
That does presume, however, that there are no other target rules for either target1 or target2. If the last-appearing rule for target2 that provides a recipe is a different one than the last-appearing rule for target1 that provides a recipe, then two recipes will run: one to generate target1 (maybe with a side effect of also generating target2), and the other to generate target2 (maybe with a side effect of also generating target1). The relative order of those is unspecified, and the result might be inconsistent.
You should also read the Automake manual's comments on tools and rules that generate multiple targets.
To extend this question a bit, if prereq3 was auto generated during the make process, how would this play out?
No differently than already described, at least for GNU make. It is possible that the construction you describe was motivated by a misunderstanding of this issue, or perhaps that it targeted the implementation-specific behavior of some other make implementation than GNU's, but if, currently, the software builds correctly with GNU make then removing the first rule just converts the resulting makefile to a POSIX-conforming one (in this respect), with no reason to expect any change in behavior.
There may be nuances and alternative solutions associated with the specifics of your situation, but all of the above comments apply regardless of any such details.
If make is run in parallel, could this cause big issues?
Rule duplication of the form you describe has no particular interaction with parallel make. However, you will likely run into issues with parallel make if you do not express the full dependencies of each target, and especially the dependencies on other built targets. But note that you don't generally need to express dependencies on C or C++ header files, even built ones, because Automake-generated makefiles include code for detecting and tracking these automatically.
BUT, if you have other target rules that provide recipes for one or both targets, as mentioned above, then yes, that will be an issue for parallel make. Do yourself a favor, and ensure that no target has a recipe specified by more than one target rule.
Also, although the rule duplication might not be an issue for parallel make, if one run of the recipe generates both targets, then that might create issues for parallel make. Refer to the Automake manual, linked above, for more commentary on that point.
Assuming you are using gnu make, the warning indicate that the first rule is ignored. Running make with lol execute the ACTION from the 2nd recipe. The ACTION from the first recipe can removed (which will remove the warnings!).
make
Makefile:5: warning: overriding recipe for target 'target1'
Makefile:2: warning: ignoring old recipe for target 'target1'
Makefile:5: warning: overriding recipe for target 'target2'
Makefile:2: warning: ignoring old recipe for target 'target2'
echo "Action2"
Action2
Quoting from gnu make manual: https://www.gnu.org/software/make/manual/make.html
warning: overriding recipe for target xxx'
warning: ignoring old recipe for targetxxx'
GNU make allows only one recipe to be
specified per target (except for double-colon rules). If you give a
recipe for a target which already has been defined to have one, this
warning is issued and the second recipe will overwrite the first. See
Multiple Rules for One Target.
I have a Makefile:
.PHONY: all
all: target1
target1:
$(info "target1")
target1:
$(info "target1 override")
If to execute "make" from a bash it will respond:
$ make
Makefile:8: warning: overriding recipe for target 'target1'
Makefile:5: warning: ignoring old recipe for target 'target1'
"target1 override"
make: Nothing to be done for 'all'.
This behavior is expected by me, because I expect that the latest definition of the target will be taken by Makefile's parser.
Is it legal to expect that the latest rule from the Makefile will be taken if the rule is overridden?
Is it possible to get rid of warnings?
P.S. Also I have tried answers from another StackOverflow's questions like the use of "override" keyword and "::" symbols. It doesn't help (errors and the same warnings from Makefile appears).
Is it legal to expect that the latest rule from the Makefile will be
taken if the rule is overridden?
A makefile that contains multiple target rules that provide recipes for the same target violates the POSIX specifications for make:
Only one target rule for any given target can contain commands.
Violating that will not bring the police down on you, but it may, rightfully, bring down the wrath of other developers and managers who have to work with your code, now or later. Implementations of make are not bound by the spec to any particular behavior when a makefile containing such multiple recipes is presented.
The diagnostic messages you present and the behavior you describe appear characteristic of GNU make. To the extent that you are willing to be dependent on that particular make implementation, it would be reasonable to rely on section 4.11 of its manual, which says:
There can only be one recipe to be executed for a file. If more than
one rule gives a recipe for the same file, make uses the last one
given and prints an error message.*
(Footnote mine.) But reliance on that renders your makefile non-portable. Other make implementations might instead reject the makefile, choose the first recipe, choose a random recipe, choose all matching recipes in some order, or exhibit any manner of obvious or non-obvious breakage. Alerting you to that is the purpose of the message.
Is it possible to get rid of warnings?
Continuing to assume GNU make, the manual says definitively that a diagnostic will be emitted, and its summary of command-line options does not describe any that I would expect to suppress the output in question without also suppressing the actual build.
Bottom line
The question conveys the impression that you think the usage described ought to be acceptable, so that the diagnostic is merely a nuisance. This is not the case. Such usage is poor style, at least, and it can present genuine problems for yourself and others. Whatever you're trying to accomplish that way, there are better alternatives.
*It's referring to target rules. Suffix and pattern rules that match the target are a different matter.
In the comments of this answer, MadScientist, the current maintainer of GNU Make says on explicitly declared .INTERMEDIATE targets:
[a file] just has to be mentioned explicitly in any rule (not recipe) to remove its eligibility for intermediate status.
On the other hand, the GNU make manual says
However, you can explicitly mark a file as intermediate by listing it as a prerequisite of the special target .INTERMEDIATE. This takes effect even if the file is mentioned explicitly in some other way.
Which is right or what did I get wrong?
There's a misunderstanding: both of the above statements are true, but the context you apply (on explicitly declared .INTERMEDIATE targets) is not correct; that statement was in response to a question asked in a comment to my answer, which was different than the original question.
With no special overrides, a target is eligible to be intermediate if it's completely inferred by make (not listed anywhere explicitly in the makefile but only discovered through implicit rule search).
If a target is listed as a target or prerequisite in a makefile, then it is not eligible to be intermediate by default. The .INTERMEDIATE special form allows you to declare that a target that is mentioned to be intermediate even so.
To ensure a target is not intermediate, it's enough to simply mention it in the makefile as a target or prerequisite of some target, somewhere (doesn't have to be one that is actually built during that invocation of make).
To ensure a target is intermediate, it either should not be mentioned or else it should be declared a prerequisite of .INTERMEDIATE.
I have a generator program that creates two version files, say ver.h and ver.cpp. My ultimate build target depends on both of these files, and the rule for building both is that one program. If I did this:
build : ver.h ver.cpp
ver.h ver.cpp :
./gen/version/program
then a parallel build could run program twice, which, while not bad is just excessive. I figure I could have them both depend on a phony target:
ver.h ver.cpp : do-version-impl
do-version-impl:
./gen/version/program
.PHONY : do-version-impl
Is that the best way to do this? It smells a little funny to have to introduce a phony rule to do this.
Using the phony target as the prerequisite is a bad idea. program will be run even if ver.* files exist, which is a false positive error.
More subtly, GNU Make is only guaranteed to update its file timestamp, if that file is a target of a rule with a recipe. So here, even though program is always run, anything that in turn depends on ver.* files might not get updated at all!
In my opinion it is best to not make up unnatural patterns for each target, but instead, go explicit:
There is a "main" file that you are generating, that is ver.cpp. Use the "no-op" recipe ; for the other one, which can be put on the same line like this:
ver.h: ver.cpp ;
ver.cpp: Makefile
./gen/version/program
This method starts with what you wrote, but adds the very important ;.
If you did not have a natural candidate for the "main" file, then in my opinion it is best to use a "sentinel":
ver.h ver.cpp: sentinel ;
sentinel: Makefile
./gen/version/program
touch $#
Again, this method is similar to one of your methods, but very importantly, does not use a phony, but a real file.
See 10.5.1 Introduction to Pattern Rules specifically the last paragraph:
10.5.1 Introduction to Pattern Rules
...
A pattern rule need not have any prerequisites that contain ‘%’, or in fact any prerequisites at all. Such a rule is effectively a general wildcard. It provides a way to make any file that matches the target pattern. See Last Resort.
...
Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and recipe. If a pattern rule has multiple targets, make knows that the rule’s recipe is responsible for making all of the targets. The recipe is executed only once to make all the targets. When searching for a pattern rule to match a target, the target patterns of a rule other than the one that matches the target in need of a rule are incidental: make worries only about giving a recipe and prerequisites to the file presently in question. However, when this file’s recipe is run, the other targets are marked as having been updated themselves.
So you could use something like this:
v%r.h v%r.cpp:
./gen/version/program
I believe you need that odd patterning to have make consider the pattern to match (I don't believe it will match % against an empty string as ver%.h ver%.cpp would need). (I can't find reference to this in the manual at the moment though.)
I am working on a Makefile written by someone else in my lab and I see the following:
include /path/to/Makefile.inc
TARGET_A: pre_req_1 pre_req_2
cmd_1;
cmd_2;
...
When I look at /path/to/Makefile.inc I see that it also includes a target TARGET_A
with other pre-requisites and recipes.
Is this a normal practice? (and would it work?) Would make treat the two rules separately? Can we safely make any assumptions about which one is considered first?
It is a dangerous practice since it is confusing to know which one is applied.
The "include" will act has if the included file content was in the Makefile, and the targets will be overrided while reading the Makefile. So, the last target will be honored, and the first one (in the included file) will be ignored.