I have a Makefile with tons of targets and would like for a certain script to get executed first, irrespective of what target is being called. I like to call it a global prerequisite.
I do not want to create a target for the script and set it as a prerequisite for all existing targets (which, as I said aren't few). Besides, someone else could add a target in future and not add my script as a prerequisite for their target, so the global prerequisite would take care of that.
Does GNU-make provide for a means to achieve this?
Another approach:
-include dummy
.PHONY: dummy
dummy:
run-the-script
Make will always attempt to rebuild any file which the makefile attempts to include (if it is out of date or does not exist). In this case there is no such file, and the rule to build it runs the script and does nothing else.
There is a solution without modifying your existing Makefile (main difference with the answers pointed to by tripleee). Just create a makefile containing:
.PHONY: all
all:
pre-script
#$(MAKE) -f Makefile --no-print-directory $(MAKECMDGOALS) MAKE='$(MAKE) -f Makefile'
post-script
$(MAKECMDGOALS): all ;
The only drawback is that the pre- and post- scripts will always be run, even if there is nothing else to do. But they will not be run if you invoke make with one of the --dry-run options (other difference with the answers pointed to by tripleee).
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 have a make file with some pattern rules¹ that end up as prerequisites for another rule. A minimum example that shows the symptoms I'm puzzled by is this:
.PHONY: clean default one two
default: clean one two
clean:
#rm -f {one,two}.{a,b}
one two: %: %.a %.b
#echo TARGET $# PREREQUISITES $^
%.a %.b:
#echo Prereq $#
#touch $#
The output I expect when running this would be:
Prereq one.a
Prereq one.b
TARGET one PREREQUISITES one.a one.b
Prereq two.a
Prereq two.b
TARGET two PREREQUISITES two.a two.b
Instead, only the first prerequisite gets built, make gives me this:
Prereq one.a
TARGET one PREREQUISITES one.a one.b
Prereq two.a
TARGET two PREREQUISITES two.a two.b
As you can see, the recipe itself parses these correctly and knows that it should have been built after both prerequisites, but the prerequisite rule hasn't actually been run.
Incidentally, I'm using order-only prerequisites for the second item here but it doesn't really matter: the same problem is exhibited either way.
If I run the same target a second time, then it builds the second prerequisite. In other words two passes finally gets me the result I need:
$ make clean
$ make one
Prereq one.a
TARGET one PREREQUISITES one.a one.b
$ make one
Prereq one.b
TARGET one PREREQUISITES one.a one.b
The first time it runs, only the first prerequisite exists and I'm left with a broken one. On the second pass one.a exists, so it decides to build one.b. Now that both prerequisites exist my one builds properly.
If I spell out the prerequisite target variations as two separate recipes (repeat the same block for both %a: and %.b patterns separately) then both prerequisites get built for each target. However this would make my file quite a bit more complex and I'd like to understand why this breaks.
¹ This make file has some other problems but I've isolated this issue to an reproducible case so I don't think its other idiosyncrasies are the issue here.
GNU Make has what we may consider a little "quirk" in the sense that multiple-target pattern rules don't work exactly like several rules. In this situation, the rule is triggered only once by a single target, and Make expects the rule to make all targets at once. From the GNU Make documentation:
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. [...]
So what is happening here is:
checks the dependencies for one: finds one.a and one.b from the pattern %: %.a %.b;
finds one pattern rule for both one.a and one.b;
executes the recipe with target ($#) set to one.a (the one that triggered the rule);
marks both one.a and one.b as updated, even though the recipe only created one.a;
thinks all depencies for one have been satisfied and go on to do the same with two.
The reason why Make touches different files when you call it again is because now one.a and two.a are up-to-date. So the targets that trigger the rule become one.b and two.b. If you remove only one.a before calling Make a second time, it will create one.a and two.b.
So you have at least three possible solutions. One is to spell out the targets that behave like you'd expects—which you said is not a good solution, but it's worth mentioning here anyway. Another is to break that %.a %.b into two rules, which achieves the same but might be easier considering your needs. And the third is to do what Make expects and create both targets in the same recipe—e.g., you can use the stem in the recipe:
%.a %.b:
#echo Processing target $# from stem $*
touch $*.a $*.b
Another thing that I noticed while looking into this problem is that your MCVE's clean is broken. By default, Make will use /bin/sh, which will not expand things like {a,b}. You can set SHELL=/bin/bash to change that.
I'm just starting to really grok the inner workings of make. Yet I do not understand why the following doesn't work:
test%: test%.foo
#echo $#
#echo $<
all: test1 test2
.PHONY: all test1 test2
Expected behavior:
$ make
test1
test1.foo
test2
test2.foo
# 1,2 Order not important
However, I get:
$ make
make: Nothing to be done for `all'.
("make all", "make test1", etc make no difference).
Can someone explain why the PHONY test rules aren't being executed?
Excerpt from the GNU make manual.
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 section Using Implicit Rules). This is why
declaring a target phony is good for performance, even if you are not
worried about the actual file existing.
This means that as your test1 and test2 targets are phony, make does not search for implicit rules for them. Even if what you use is more accurately named pattern rules, all pattern rules are implicit rules.
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