I have a Makefile:
.PHONY: target0 target1
target0:
<command>
target1: target0
<command>
How can I run make target1 and force it to skip target0?
Neither GNU make nor any other make I know provides a means to ignore out-of-date prerequisites. It is antithetical to make's design and goals. Targets that don't exist or (with GNU make) that are .PHONY are always considered out-of-date at the beginning of a run. So, with that makefile, make target1 will always build target0 as well.
That you pose the question at all suggests that you have modeled something as a prerequisite that isn't really a prerequisite. Perhaps you did so to aggregate targets, for example. In that case, you could consider rewriting your makefile, maybe like so:
.PHONY: all target0 target1
target0:
<command>
target1:
<command>
all: target0 target1
With that, you can build just target0 or just target1 or both (all), as you choose, but you do need to request both when that's in fact what you want. When you do request both, you will probably get target0 built before target1 unless you use the -j option. But if you need to ensure that target0 is built first when both are to be built, then you could do this, instead:
.PHONY: all target0 target1
target0:
<command>
target1:
<command>
all:
make target0
make target1
With GNU make:
make -W target0 target1
From the manual
on "Instead of Executing Recipes":
Each ‘-W’ flag is followed by a file name. The given files’ modification
times are recorded by make as being the present time, although the actual
modification times remain the same.
Without the ‘-n’ or ‘-q’ flag, when make is actually executing recipes,
the ‘-W’ flag can direct make to act as if some files had been modified,
without actually running the recipes for those files.
Related
Does order in makefile all target matters ?
For eg. if I have -
all : target1 target2 target3
Does the order matters here i.e. will target2 be always executed after target3 ?
The POSIX standard for make requires that make consider prerequisites in the order they were listed in the makefile.
So yes, in your example make is required to first try to build target1, then try to build target2, then try to build target3, then, if any of those targets were updated, it will try to run the recipe for all if one exists.
However, it's a bad idea to rely on this when you write your makefile.
First, what if someone runs make target3 but you can't build target3 until target2 is complete? Then make target3 will not try to build target2 because make doesn't know that it's needed.
Second, if you invoke make -j (parallel builds) then make can try to build target1, target2, and target3 all at the same time. If they rely on each other this will likely break things.
If you have a dependency relationship between two targets, you should tell make about it by declaring a prerequisite. That way you know your build is reliable.
I want to be able use the result of a target created in a rule in the prerequisite of another rule in GNU make. So for example:
PREREQ = $(shell echo "reading target1" >&2; cat target1)
target1:
echo "prereq" > $#
target2: target1 $(PREREQ)
echo foo > $#
target2 should depend on prereq as read from the target1 file, but that is not in the file until the target1 recipe is executed.
Granted this is very contrived example with I am sure lots of suggestions about how to refactor this particular example but I'm not looking to refactor this example. This is just a simplified example of my more complicated problem where I need to derive prerequisites from the contents of a file that is not created until a recipe in the Makefile is executed.
The question is, [how] can I make expansion of $(PREREQ) (and therefore the execution of the $(shell cat target1) defer until after the target1 rule is actually executed?
Update: I tried .SECONDARYEXPANSION: but that doesn't seem to do the job:
$ make -d target2
...
reading target1
cat: target1: No such file or directory
...
Updating goal targets....
Considering target file 'target2'.
File 'target2' does not exist.
Considering target file 'target1'.
File 'target1' does not exist.
Finished prerequisites of target file 'target1'.
Must remake target 'target1'.
echo "prereq" > target1
[ child management ]
Successfully remade target file 'target1'.
Finished prerequisites of target file 'target2'.
Must remake target 'target2'.
echo foo > target2
[ child management ]
Successfully remade target file 'target2'.
As you can see, "reading target" was only printed once at the very beginning demonstrating that PREREQ is not expanded again due to the .SECONDEXPANSION: and the list of targets Considered for target2 did not include prereq.
Deferring the expansion of the prerequisite $(PREREQ) can be achieved by conditionally creating the target2 and relying on recursion:
ifndef expand-prereq
target2: target1
$(MAKE) --no-print-directory -f $(lastword $(MAKEFILE_LIST)) $# expand-prereq=y
else
target2: target1 $(PREREQ)
echo foo > $#
endif
The first time make runs for this makefile, the variable expand-prereq is not defined and therefore, the first targe2 rule is generated as a result of the conditional. This kind of dummy rule makes possible to update target1 without expanding $(PREREQ).
Matching this rule results in target1 being updated (since target1 is a prerequisite of this rule) and make being called recursively for the same makefile and with target2 as target.
The second time make is (recursively) invoked, the variable expand-prereq was defined by means of the command-line argument expand-prereq=y, so the second target2 rule is generated as a result of the else branch this time. This rule is the one that actually produces the target target2. Note that before this rule can be matched, target1 has been already created as a side effect of the first dummy rule, so the expansion of $(PREREQ) happens after target1 has been created (what you were looking for).
You could write the complete rule for target2 to a separate file and -include it:
Including Other Makefiles
How Makefiles Are Remade
The exact mechanics will depend on your specific use case, and it may well be impossible to achieve what we need using this approach, but it supports a variety of styles for automated dependency generation.
There are several solutions:
GNU make 4.4 has been released! Haven't tried yet, but the release notes claim that secondary expansion only expands the prerequisites when they're considered. Furthermore you can delay execution with the .WAIT special prerequisite. That works fine, I tested. If .WAIT really delays the second expansion of the prerequisites after .WAIT, you're good.
Recursive make. Restart make after the prerequisites for the second rule were updated. This is a bit lame solution, can't recommend it.
Produce the prerequisites into make include file(s). Make automatically restarts after updating include files (re-exec). I'm currently using this method, and it works great. Better than recursive make but still slow, as all the makefiles have to be parsed again. A possible solution is comparing the old and new prerequisites, and only updating the include file, if its content changed. The second rule also needs to be modified to do nothing, if the content changed. Make will run all rules before restarting, but if they don't update their targets, after the restart they'll be executed again, now with the proper prerequisites. An interesting feature of make is that you can define make variables inside a recipe, and use them in other recipes (but not in the prereq list, unless #1 above reall works).
I have a Makefile with the following format:
.PHONY: all
target1 := file1
target2 := $(target1).txt
all: $(target2)
$(target1): prerequisite1
recipe
$(target2): $(target1)
recipe
target2 depends on target1, and make will correctly substitute the strings to create the file names. However, on my system, the file names and paths are quite tedious to type out; I'm wondering if there is any
way to specifically make target1 while referring to its name not as the file path, but as the variable.
For example, I would like to be able to invoke:
$ make $(target1)
rather than
$ make path/to/file1
I want to do this because I change the variables quite a bit and the structure of my Makefile has many intermediates that are occasionally difficult to trace back to their literal file paths, but are easy to make based on the variable names that I have assigned them.
The above does not work, and I have read the man page as well as done quite a bit of searching here and on Google. Just wondering if anyone has come across this problem before and found a solution.
This is a bit clunky to due use of recursion, but it does what you want:
target1 := file1
$(target1):
#echo "Hello from $#"
variable-%:
$(MAKE) $($*)
gives
$ make variable-target1
make file1
Hello from file1
That's what phony targets are for. A phony target is a target that isn't the name of an output file. Often, the default target (that's whatever target appears first in the Makefile) is phony and by convention called all. So just modify your Makefile to something like this:
.PHONY: all target1 target2
target1 := file1
target2 := $(target1).txt
# phony rules with dependencies
all: target2
target2: $(target2) target1
target1: $(target1)
# file rules with prerequisites
$(target1): prerequisite1
recipe
$(target2):
recipe
As a "best practice", list the dependencies that aren't directly used for creating the real targets in the prerequisite list of the phony targets and the dependencies that are indeed input files in the prerequisite list of the actual file targets.
Note this will work without declaring the targets in .PHONY as long as there's not by accident a file with the name of the phony target. Such a file would confuse make, therefore always list all your phony targets in .PHONY, so make knows they don't produce a file of their name.
I am wondering if the order-only prerequisite loses its order-only precedence if it is a phony target. Consider the following:
%.make: unpack_chroot
schroot $(CHROOT) make $*
%.copy: | unpack_chroot
rsync -a input/$*/ $(CHROOT)/input/$*/
unpack_chroot: input/chroot.tar.gz
mkdir -p $(CHROOT)
tar -C $(CHROOT) -zxf $<
.PHONY: unpack_chroot
All %.make and %.copy targets are .PHONY. Some of these targets depend on files being copied into the chroot, others do not. Those that do are defined with explicit dependencies:
a.make: a.copy
c.make: c.copy
However, if unpack_chroot is not an order-only prerequisite and was unpacked as part of the processing of prerequisites for another make target not in the same make process, unpack_chroot will be considered up-to-date when %.copy runs and will not remake %.copy; at least that is what I have seen. Currently, unpack_chroot is not phony and gets created. I want to make it phony, but want to clarify the behaviour.
According to this email ( http://kolpackov.net/pipermail/notes/2004-January/000001.html ) it seems that the only difference between normal and order only prerequisites is that the latter will not be included in automatic make variables such as $^.
From some tests I ran it seems that this is the only difference. In all other respects they are treated the same as normal prerequisites.
What does .PHONY mean in a Makefile? I have gone through this, but it is too complicated.
Can somebody explain it to me in simple terms?
By default, Makefile targets are "file targets" - they are used to build files from other files. Make assumes its target is a file, and this makes writing Makefiles relatively easy:
foo: bar
create_one_from_the_other foo bar
However, sometimes you want your Makefile to run commands that do not represent physical files in the file system. Good examples for this are the common targets "clean" and "all". Chances are this isn't the case, but you may potentially have a file named clean in your main directory. In such a case Make will be confused because by default the clean target would be associated with this file and Make will only run it when the file doesn't appear to be up-to-date with regards to its dependencies.
These special targets are called phony and you can explicitly tell Make they're not associated with files, e.g.:
.PHONY: clean
clean:
rm -rf *.o
Now make clean will run as expected even if you do have a file named clean.
In terms of Make, a phony target is simply a target that is always out-of-date, so whenever you ask make <phony_target>, it will run, independent from the state of the file system. Some common make targets that are often phony are: all, install, clean, distclean, TAGS, info, check.
Let's assume you have install target, which is a very common in makefiles. If you do not use .PHONY, and a file named install exists in the same directory as the Makefile, then make install will do nothing. This is because Make interprets the rule to mean "execute such-and-such recipe to create the file named install". Since the file is already there, and its dependencies didn't change, nothing will be done.
However if you make the install target PHONY, it will tell the make tool that the target is fictional, and that make should not expect it to create the actual file. Hence it will not check whether the install file exists, meaning: a) its behavior will not be altered if the file does exist and b) extra stat() will not be called.
Generally all targets in your Makefile which do not produce an output file with the same name as the target name should be PHONY. This typically includes all, install, clean, distclean, and so on.
NOTE: The make tool reads the makefile and checks the modification time-stamps of the files at both the side of ':' symbol in a rule.
Example
In a directory 'test' following files are present:
prerit#vvdn105:~/test$ ls
hello hello.c makefile
In makefile a rule is defined as follows:
hello:hello.c
cc hello.c -o hello
Now assume that file 'hello' is a text file containing some data, which was created after 'hello.c' file. So the modification (or creation) time-stamp of 'hello' will be newer than that of the 'hello.c'. So when we will invoke 'make hello' from command line, it will print as:
make: `hello' is up to date.
Now access the 'hello.c' file and put some white spaces in it, which doesn't affect the code syntax or logic then save and quit. Now the modification time-stamp of hello.c is newer than that of the 'hello'. Now if you invoke 'make hello', it will execute the commands as:
cc hello.c -o hello
And the file 'hello' (text file) will be overwritten with a new binary file 'hello' (result of above compilation command).
If we use .PHONY in makefile as follow:
.PHONY:hello
hello:hello.c
cc hello.c -o hello
and then invoke 'make hello', it will ignore any file present in the pwd 'test' and execute the command every time.
Now suppose, that 'hello' target has no dependencies declared:
hello:
cc hello.c -o hello
and 'hello' file is already present in the pwd 'test', then 'make hello' will always show as:
make: `hello' is up to date.
.PHONY: install
means the word "install" doesn't represent a file name in this
Makefile;
means the Makefile has nothing to do with a file called "install"
in the same directory.
It is a build target that is not a filename.
The special target .PHONY: allows to declare phony targets, so that make will not check them as actual file names: it will work all the time even if such files still exist.
You can put several .PHONY: in your Makefile :
.PHONY: all
all : prog1 prog2
...
.PHONY: clean distclean
clean :
...
distclean :
...
There is another way to declare phony targets : simply put :: without prerequisites :
all :: prog1 prog2
...
clean ::
...
distclean ::
...
The :: has other special meanings, see here, but without prerequisites it always execute the recipes, even if the target already exists, thus acting as a phony target.
The best explanation is the GNU make manual itself: 4.6 Phony Targets section.
.PHONY is one of make's Special Built-in Target Names. There are other targets that you may be interested in, so it's worth skimming through these references.
When it is time to consider a .PHONY target, make will run its recipe
unconditionally, regardless of whether a file with that name exists or
what its last-modification time is.
You may also be interested in make's Standard Targets such as all and clean.
There's also one important tricky treat of ".PHONY" - when a physical target depends on phony target that depends on another physical target:
TARGET1 -> PHONY_FORWARDER1 -> PHONY_FORWARDER2 -> TARGET2
You'd simply expect that if you updated TARGET2, then TARGET1 should be considered stale against TARGET1, so TARGET1 should be rebuild. And it really works this way.
The tricky part is when TARGET2 isn't stale against TARGET1 - in which case you should expect that TARGET1 shouldn't be rebuild.
This surprisingly doesn't work because: the phony target was run anyway (as phony targets normally do), which means that the phony target was considered updated. And because of that TARGET1 is considered stale against the phony target.
Consider:
all: fileall
fileall: file2 filefwd
echo file2 file1 >fileall
file2: file2.src
echo file2.src >file2
file1: file1.src
echo file1.src >file1
echo file1.src >>file1
.PHONY: filefwd
.PHONY: filefwd2
filefwd: filefwd2
filefwd2: file1
#echo "Produced target file1"
prepare:
echo "Some text 1" >> file1.src
echo "Some text 2" >> file2.src
You can play around with this:
first do 'make prepare' to prepare the "source files"
play around with that by touching particular files to see them updated
You can see that fileall depends on file1 indirectly through a phony target - but it always gets rebuilt due to this dependency. If you change the dependency in fileall from filefwd to file, now fileall does not get rebuilt every time, but only when any of dependent targets is stale against it as a file.
I often use them to tell the default target not to fire.
superclean: clean andsomethingelse
blah: superclean
clean:
#echo clean
%:
#echo catcher $#
.PHONY: superclean
Without PHONY, make superclean would fire clean, andsomethingelse, and catcher superclean; but with PHONY, make superclean won't fire the catcher superclean.
We don't have to worry about telling make the clean target is PHONY, because it isn't completely phony. Though it never produces the clean file, it has commands to fire so make will think it's a final target.
However, the superclean target really is phony, so make will try to stack it up with anything else that provides deps for the superclean target — this includes other superclean targets and the % target.
Note that we don't say anything at all about andsomethingelse or blah, so they clearly go to the catcher.
The output looks something like this:
$ make clean
clean
$ make superclean
clean
catcher andsomethingelse
$ make blah
clean
catcher andsomethingelse
catcher blah