I have a source code folder structure as follows
src
|-tests
|-abc
I have a makefile in src which has a target called tests. tests has its own makefile which it uses to compile the source code into binary.(multiple targets).All that is managed by the Makefile in the test directory.
My src make file has the following targets.
all: main tests
main: $(DEPENDENCY IN SRC and ABC)
command
tests: ??
make -C tests
What dependancy can I specify for tests target in the main Makefile.. I don't want this Makefile to be aware of the source files in the tests folder.
all: main tests
main: $(DEPENDENCY IN SRC and ABC)
command
tests:
$(MAKE) -C tests
this will unconditionally invoke make of tests on its private subdirectory. Note that usage of special $(MAKE) variable helps to propagate command-line parameters and reduces overhead.
Just declare the target as PHONY meaning that make will not check for any produced file. Instead it just always executes the rule, letting the secondary call to make to decide what needs to be built.
Think about this: What happens if you have an aditional file src/tests? make will notice that the file already exists and, as no prerequisite is indicated, it will decide not to make that file. Preventing your rule tests from being executed.
all: main tests
main: $(DEPENDENCY IN SRC and ABC)
# Recipes (That is the word to describe commands in a make rule)
.PHONY: tests
tests:
$(MAKE) -C tests
Also add the answer by Alex: using $(MAKE) is a good practice. And allows your makefiles to work independently from the name of the make program. Imagine that you have a distribution where the program is called xyz-make.
I don't want this Makefile to be aware of the source files in the tests folder.
Perhaps, but you may want to reconsider. Peter Miller's Recursive Make Considered Harmful makes a strong case that one Makefile is all you ever need, or want. It changed my mind a long time ago.
Related
Here is Makefile as following, I want to ask what step1 and 2 will do seperately? thanks
DIRS = modules utils library
BUILDDIRS = $(DIRS:%=build-%) step1
all: $(BUILDDIRS)
$(BUILDDIRS):
$(MAKE) -C $(#:build-%=%) step2
This looks like a dispatching Makefile. Its job is to expose the build targets build-modules, build-utils and build-library. If it is not given any target, it builds the all target which depends on all of these. We can also think about, for instance, make build-utils being directly invoked.
Each build-<whatever> corresponds to a <whatever> dir without the build- prefix.
For instance to update the target build-utils, the action is to recursively invoke make with -C utils step2 as the arguments: change to the utils directory and look for a Makefile there, invoking its step2 target.
This Makefile has a flaw: the targets all and the build-<dir> targets are all phony, but there is no .PHONY: declaration for them. This means that make will probe the filesystem, looking for files named all, and build-modules, etc. If you create files with these names, such as by touch build-modules or touch all, the Makefile will then malfunction.
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 something like this in my makefile :
JAR = jar1.jar
run:
java -cp $(JAR)
what i want to do is for the makefile to do run multiple times but with each iteration, it uses another jar, they're all called jarx.jar with x going from 1 to 10 for example
is it possible to do it without passing the jar name inside the statement? the example i gave is quite simple for the sake of simplicity but the actual makefile i'm working with is already quite complicated...
make uses filesystem objects to keep state. A common solution to keeping track of things which are not directly visible as files in the current directory is to create a local flag file.
JARS := first.jar 2nd.jar thirdjar.jar
.PHONY: all run
all: $(patsubst %, .made-%,$(JARS))
run: all
.made-%.jar: %.jar
java -cp $<
touch $#
So the existence of .made-first.jar signals to Make that this target has been performed for the prerequisite first.jar, etc.
If you have a clean target, or at least realclean, it should probably clean up all the flag files.
I read some tutorials concerning Makefiles but for me it is still unclear for what the target "all" stands for and what it does.
Any ideas?
A build, as Makefile understands it, consists of a lot of targets. For example, to build a project you might need
Build file1.o out of file1.c
Build file2.o out of file2.c
Build file3.o out of file3.c
Build executable1 out of file1.o and file3.o
Build executable2 out of file2.o
If you implemented this workflow with makefile, you could make each of the targets separately. For example, if you wrote
make file1.o
it would only build that file, if necessary.
The name of all is not fixed. It's just a conventional name; all target denotes that if you invoke it, make will build all what's needed to make a complete build. This is usually a dummy target, which doesn't create any files, but merely depends on the other files. For the example above, building all necessary is building executables, the other files being pulled in as dependencies. So in the makefile it looks like this:
all: executable1 executable2
all target is usually the first in the makefile, since if you just write make in command line, without specifying the target, it will build the first target. And you expect it to be all.
all is usually also a .PHONY target. Learn more here.
The manual for GNU Make gives a clear definition for all in its list of standard targets.
If the author of the Makefile is following that convention then the target all should:
Compile the entire program, but not build documentation.
Be the the default target. As in running just make should do the same as make all.
To achieve 1 all is typically defined as a .PHONY target that depends on the executable(s) that form the entire program:
.PHONY : all
all : executable
To achieve 2 all should either be the first target defined in the make file or be assigned as the default goal:
.DEFAULT_GOAL := all
Not sure it stands for anything special. It's just a convention that you supply an 'all' rule, and generally it's used to list all the sub-targets needed to build the entire project, hence the name 'all'. The only thing special about it is that often times people will put it in as the first target in the makefile, which means that just typing 'make' alone will do the same thing as 'make all'.
The target "all" is an example of a dummy target - there is nothing on disk called "all". This means that when you do a "make all", make always thinks that it needs to build it, and so executes all the commands for that target. Those commands will typically be ones that build all the end-products that the makefile knows about, but it could do anything.
Other examples of dummy targets are "clean" and "install", and they work in the same way.
If you haven't read it yet, you should read the GNU Make Manual, which is also an excellent tutorial.
I have a project that I am working to release that actually contains 3 subprojects, all of which need to be compiled in one go. My makefile looks roughly like this:
all: a b c
a:
#cd a && make
b:
#cd b && make
c:
#cd c && make
Projects A and B both compile fine but for the 3rd project, it tells me there is nothing to be done although switching to the C directory and running make does in fact compile code.
To be a little more specific: Project C in the example above is actually Mozilla's SpiderMonkey. Whereas A and B are code/makefiles that I have written, C is just a raw copy of SpiderMonkey from the Mozilla website. The actually compile command for it is:
make JS_DIST=/usr JS_THREADSAFE=1 JS_HAS_FILE_OBJECT=1
In my master Makefile, I have:
spidermonkey:
#cd spidermonkey/src && $(MAKE) JS_DIST=/usr JS_THREADSAFE=1 JS_HAS_FILE_OBJECT=1
Running "make spidermonkey" outputs "make: Nothing to be done for `spidermonkey'." How do I get make to run the command?
EDIT:
I've tried adding the following lines to my makefile:
.PHONY: spidermonkey
As well as renaming the spidermonkey rule to sm, but still no change.
EDIT:
My bad! I had spaces when I should have had a tab. doh!
You probably have a file or directory at the toplevel called "spidermonkey". Make thinks this is what its supposed to create, and since it is already there, make stops.
One of the most important rules to follow when writing makefiles is each target should create one file with the same name as the target. In other words, if you have
a:
<some command>
That command should produce a single file called "a".
Rules which do not produce files but are only there as placeholders are called phony targets, and they should be declared like this:
.PHONY: a
Make will then always assume that a has to be remade.
Also, as a general rule do not use "make" to invoke make recursively, use $(MAKE) instead.
EDIT: changed "pseudo" to "phony"
Make only checks for the existance of a file (or directory) named the same as the rule target, and if there is (and it is newer than the dependencies) then from make's point of view there is nothing more to do.
So your problem is that you have a spidermonkey rule (with no dependencies) as well as a directory called spidermonkey, and then make thinks "the target is already made, nothing for me to do". To get make to do what you want, rename the spidermonkey rule (or the directory).
Speaking of recursive make by the way, this is not neccessarily a good idea,
see Recursive Make Considered Harmful.