Are these two formulations equivalent in Makefile, in terms of order of evaluation?
rule: dep1
rule: dep2
and
rule: dep1 dep2
I don't know what you mean exactly by "order of evaluation", but in both cases make will try to build first dep1 and then dep2, guaranteed. In a parallel build situation they might be both run at the same time, but dep1 will always be started first.
I should say that if your makefile was more complicated there are other things that could change the order. For example, prerequisites in an explicit or implicit rule are always tried first.
Also, if the prerequisites of dep1 and dep2 took different amounts of time and you were running in parallel, dep2 might be started before dep1.
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 that basically looks like this:
DIRS = a
all : $(DIRS)
DIRS += b
a b:
# echo $#
I was surprised to discover that only a gets printed. Why? I thought the whole advantage of recursive expansion was that I can expand my variables in arbitrary order for convenience. Is there a way to get the behavior I want for the prerequisites of all?
The problem is that make has already expanded $(DIRS) by the time you append to it.
From 3.7 How make Reads a Makefile:
GNU make does its work in two distinct phases. During the first phase it reads all the makefiles, included makefiles, etc. and internalizes all the variables and their values, implicit and explicit rules, and constructs a dependency graph of all the targets and their prerequisites. During the second phase, make uses these internal structures to determine what targets will need to be rebuilt and to invoke the rules necessary to do so.
It’s important to understand this two-phase approach because it has a direct impact on how variable and function expansion happens; this is often a source of some confusion when writing makefiles. Here we will present a summary of the phases in which expansion happens for different constructs within the makefile. We say that expansion is immediate if it happens during the first phase: in this case make will expand any variables or functions in that section of a construct as the makefile is parsed. We say that expansion is deferred if expansion is not performed immediately. Expansion of a deferred construct is not performed until either the construct appears later in an immediate context, or until the second phase.
...
Rule Definition
A rule is always expanded the same way, regardless of the form:
immediate : immediate ; deferred
deferred
That is, the target and prerequisite sections are expanded immediately, and the recipe used to construct the target is always deferred. This general rule is true for explicit rules, pattern rules, suffix rules, static pattern rules, and simple prerequisite definitions.
You can always add prerequisites to targets.
So you could add all: b when you know what b is to add it to the prerequisite list for all.
You could also put all: at the top (for the default target selection) and then put all: $(DIRS) at the bottom to use the full DIRS value as prerequisites.
Lastly you could use Secondary Expansion to force an extra expansion phase that should do what you want here.
.SECONDEXPANSION:
all: $$(DIRS)
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 still don't understand why "phony" rules in Makefiles have ".PHONY" as their target. It would be much more logical as a prerequisite.
Do I have to elaborate on this? If A depends on B and B is phony, then A is phony too. So the dependency graph .PHONY←B→A is waay surprising compared to .PHONY→B→A. (Another argument is that an implementation of make must handle the .PHONY target very special.)
While this critique may seem rather theoretical (to pointless) - "since make is so ancient, its syntax is here to stay". But I am not proposing any syntax change, there is an alternative:
With GNU Make (at least), the following Makefile declares a phony target_A:
target_A: _PHONY
touch target_A
_PHONY:
#noop
Question 1: This is so simple and clean, surely I am not its first inventor. In fact, given this alternative, why did make ever need the special syntax?
It seems to me that this would also quite nicely solve questions about wildcards in phony targets, and could even shed some light on .PHONY's meaning when beginners doubt.
Question 2: Can you think of any circumstance where this approach is inferior? (Is invoking make .PHONY of any use?)
(I should mention that while I have invoked other makes, GNU Make is the only implementation that I have some experience with - reading and writing Makefiles.)
One big problem with using target_A: .PHONY is that it makes it much harder to use many of make's built-in variables. Take this common recipe as an example:
%.a: $(OBJ_FILES)
$(LD) $(LFLAGS) -o $# $^
The $^ variable pulls in everything that's listed as a prerequisite. If .PHONY was also listed there then it would be passed to the linker on the command-line, which would probably not result in anything good happening. Using meta-targets like .PHONY as prerequisites makes these built-in variables significantly less useful, as they require a lot of extra processing like $(filter-out .PHONY,$^) every time they are used. Inverting the relationship and instead making .PHONY the target is a bit awkward for the sake of thinking about dependency trees, but it cleans up the rest of the makefile.
I have a project divided in modules, each hosted in a directory, say:
root
|_module_A
|_module.cpp
|_Makefile
|_module_B
|_Makefile
|_main.c
|_Makefile
main.c depends on targets defined in Makefiles related to module_A and module_B.
I want to write my root/Makefile with respect to targets defined in Makefiles of both modules.
Now, I know that I could use the include directive, but the problem here is that targets and filenames in module_A and module_B aren't prepended with their directory, so I get something like this:
make: *** No rule to make target `module.o', needed by `main.c'. Stop.
There is a good way to solve this?
Thanks.
There are a couple of ways to do this, none of them perfect. The basic problem is that Make is good at using things there to make things here, but not the other way around.
You haven't said what the targets in module_B are; I'll be pessimistic and suppose that module_A and module_B both have targets called module (different source files, different recipes), so you really can't use include.
The biggest choice you have to make is whether to use recursive Make:
If you don't, then root/Makefile must know how to build module_A/module and module_B/module, so you'll simply have to put those rules in. Then you must either leave the redundant rules in the subdir makefiles (and run the risk that they'll drift out of agreement with the master makefile), or eliminate them, or have them call the master makefile recursively (which you wouldn't have to do very often, but it sure would look silly).
If you do, then root/Makefile will look something like this:
main: main.o module_A/module.o Module_B/module.o
...
main.o: main.c
...
%/module.o:
$(MAKE) -C $(#D) $(#F)
This will work well enough, but it will know nothing about dependencies within the subdirectories, so it will sometimes fail to rebuild an object that is out of date. You can make clean (recursively) beforehand every time, just to be on the safe side, crude but effective. Or force the %/module.o rule, which is less wasteful but a little more complicated. Or duplicate the dependency information in root/Makefile, which is tedious and untidy.
It's just a question of your priorities.
Can't you write the makefile in a non-recursive way?
Recursive Make Considered Harmful