$ ls foo.c
$ make foo cc foo.c -o foo
make(1) will detect the type of file and compile it for you, automatically naming the executable the same as the input file (gcc(1) foo.c will give you a file called a.out unless you manually specify a name for it). If you need libraries, you can specifiy them by setting the LDFLAGS variable on the command line.
Each filename (before the colon) is called a target. You can make a specific target by executing
$ make target
$ ls Makefile foo.c bar.c
$ make cc bar.c -c -o bar.o cc foo.c -c -o foo.o cc foo.o bar.o -o program
See the CompilingHowto for more info on the steps required to turn source code into an executable.
You can get your Makefiles made automatigically for you using AutoTools.
program: foo.o bar.o
Note that the line that begins "echo" must be indented by one tab. If this isn't done make(1) will abort with a weird error message like "Missing delimiter". The echo line makes a one line C file with a variable called "builddate", set to the current date and time. This is a useful thing to do for your program if you wanted to know when this particular version was compiled. (Not that this is the only way, or in fact the best way to get this information, but it's a good example.)
Why use a makefile, instead of a script to rebuild everything from scratch?
If you have a rule that reads
objectfile.o: foo.c foo.h bar.c bar.h Makefile
then make(1) will check the last modification date of objectfile.o against the last modification date of all the files that follow it (foo.c, foo.h, bar.c, bar.h and the Makefile itself). If none of these things have changed, then it won't recompile objectfile.o.
Build lines like this with careful reference to #includes in your source - if your foo.h #includes bar.h, it has to be on the Makefile line - otherwise, changes to bar.h won't cause a recompile of objectfile.o and you might get confused as to why your constants aren't what you thought they should be.
executable: foo.o bar.o
$(CC) foo.o bar.o -o executable
foo.o: foo.c foo.h Makefile bar.o: bar.c bar.h Makefile foo.h: bar.h
touch foo.h
bar.h:
So if you edit bar.h to change some constants or function definitions, Make will see that foo.h needs to be updated and 'touch' it. Then it will know it must also update foo.o in (in addition to bar.o) since foo.h appears new. This way each target only lists files that it is directly dependent on. Let make figure out the rest -- that's what it's supposed to do!
Or you could decide that mindless drone work is a waste of time and just use makedepend to spare yourself the hassle. --AristotlePagaltzis
You should consider that using this touch could affect the configuration management system you are using (e.g. RCS or CVS), if it goes by the timestamp to determine the need to commit/checkin: you might suddenly have lots of files to commit, or lots of files locked! At the very least the new timestamp will confuse your friends and confound your enemies. However, makedepends can generate an unreadable and therefore unmaintainable monstrosity, partly because it cites every system dependency (e.g. stdio), and also as it recurses through the subdep files it cites each reference to stdio by the subdeps as if it were a separate dependency. So, depending on the size of your project, and how often you have to make major adjustments by hand to the makefiles, and how many headers each file uses, you may want to decide whether or not to use this touch method (which would indeed keep the dependencies nicely hierarchical), or use makedepends. To have it both ways, I believe you could precede the touch with "cp -p foo.h foo.h_preserveDate; touch foo.h" and then under the foo.o dependency you could after the compile then do "cc foo.c; mv foo.h_preserveDate foo.h" which would preserve the original date on the foo.h checked-out file. This would still keep the hierarchical nature, which is quite valuable because it eliminates redundancy in separate places (two distant places to maintain one fact is very bad). -- LindaBrock
With larger projects you often have subdirectories with their own Makefile. To allow make to run these Makefiles with the options passed to make use the $(MAKE) variable. This variable actually callse a second make process to make the Makefile in the subdirectory. To specify the Makefile's subdirectory use the -C option of make.
all: Documentation/latex/refman.pdf
install: Documentation/latex/refman.pdf
cp Documentation/latex/refman.pdf Documentation/!KeithleyMeter?.pdf
Documentation: Doxyfile Makefile src/keithleyMeter.cc hdr/keithleyMeter.h
make clean
- make the Documentation folder
/Applications/Doxygen.app/Contents/Resources/doxygen
Documentation/latex/refman.pdf: Documentation
$(MAKE) -C Documentation/latex
%.c: %.snoz
snozzle $< -o $@
Note that foo.c is removed by make at the end -- make(1) removes intermediate files itself when it's done. Smart, eh?
%c: %.snoz
snozzle $(SNOZFLAGS) $<
would let you specify the arguments to snozzle. This is useful if you call snozzle in multiple places, but want to be able to make one change to update the flags.
CFLAGS=-g -Wall SNOZFLAGS=--with-extra-xyzzy
all: program
.PHONY: clean all
program: foo.o bar.o
%.c: %.snoz
snozzle $(SNOZFLAGS) $< -o $@
If you specify your own command line you will have to explicitly include these variables in it.
You can also check if an environment variable has been set and initialise it to something if it has not. ie.
DESTDIR ?= /usr/local
will set DESTDIR to /usr/local if it is not already defined
This allows the user to specify system specific optimizations in their shell environment.
Note : As you may have noticed, make uses $ to identify variables - both environment and defined in the file. To put a literal $ in a makefile, use $$. However, bash also uses $ to identify variables, and will consume the $ when it is passed to whatever program you're running. To therefore pass a literal $ to a program you must use \$$ - note the single \, not double. - OrionEdwards
1: CXXFLAGS=-g 2: 3: sim: car.o road.o sim.o event.o 4: g++ $(LDFLAGS) sim.o car.o road.o event.o -lm -o sim 5: 6: car.o: car.cc car.h sim.h event.h road.h Makefile 7: sim.o: sim.cc sim.h car.h road.h event.h Makefile 8: road.o: road.cc road.h sim.h event.h car.h Makefile 9: event.o: event.cc event.h sim.h Makefile
This makefile is for a car simulator written in C++. (It was written by Dr. Tony !McGregor? from TheUniversityOfWaikato).
It is possible to call some predefined functions in makefiles. A full list of them can be found in the manual, of course (http://www.gnu.org/software/make/manual/html_chapter/make_8.html#SEC83).
And then use
$(addprefix -l,$(LIBS))
in a later rule to add a -l prefix for every library mentioned in LIBS above.
Finding files in multiple directories is a good example of the usage of foreach
DIRS := src obj headers FILES := $(foreach dir, $(DIRS), $(wildcard $(dir)/*))
Then near the end of the makefile, add an
deps: $(SOURCES)
$(CC) -MD -E $(SOURCES) > /dev/null
'-E' tells gcc to stop after preprocessing. When using -E, the processed C file is sent to STDOUT. Therefore to avoid the mess on the screen, send it to /dev/null instead. Using this command all of the *.d files will be made.
deps: $(SOURCES)
$(CC) -MD -E $(SOURCES) > /dev/null
Some OperatingSystems use filesystems (such as MicrosoftWindows FAT, FAT32 and NTFS(?) and Apple's HFS) that are case insensitive, and can cause problems. (This implies you are using Cygwin on windows or Darwin on MacOSX). Particularly as unix packages often have a file named INSTALL which has installation instructions, the command "make install" says
make: Nothing to be done for install
This will tell make that the "install" target is a "phony" target, and doesn't actually refer to a file and should always be rebuilt.
If you are on an OS such as FreeBSD you might need to invoke 'gmake' for a GNU compatible make.
Shell variables in Makefiles
It's a simple change but I didn't see it written anywhere obvious :)
See Also:
I'd like to know something about makedepend and such things. Maybe some links to other or "official" make HOWTOs would be useful as well. Thanks. -- Someone
Dear Someone, Take a look at the make manual, especially section 4.14. Basically 'make depend' is not really needed anymore.
thx, !FlorianKonnertz?
This isn't really anything to do with make. The autoconf/configure methods that many projects use take a template file (such as Makefile.in) and use that to create a makefile. autoconf uses things like @CXXFLAGS@ for its variables, and should replace @...@ vars with something that makes sense to make. If you have a makefile that still has @...@ variables in it, then it's a bug and there is a bug in the package.
However, I don't know how to tell Make which is the latest file. The following grabs the first of the list.
baja.local: $(NEWSOURCES)
cp $< .
You could try using $? which gives you the names of the prerequisites which are newer than the target. If there can be several of those and you only need the latest, though, you have to do it in the recipe, using shell tools. --AristotlePagaltzis