This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
makefile aliases
Please explain $# $^ in the makefile below
LIBS = -lkernel32 -luser32 -lgdi32 -lopengl32
CFLAGS = -Wall
# (This should be the actual list of C files)
SRC=$(wildcard '*.c')
test: $(SRC)
gcc -o $# $^ $(CFLAGS) $(LIBS)
These are special variables:
$# means the target so in your case it is test.
$^ means the names of all the prerequisites, with spaces between them. In your case its the list of all the .c files.
SRC=$(wildcard '*.c') makes use of the wildcard function to get the list of all the .c files in the directory, which is then assigned to the variable SRC.
Lets say there are two C source file foo.c and bar.c. Your makefile effectively gets expanded to:
test: foo.c bar.c
gcc -o test foo.c bar.c -Wall -lkernel32 -luser32 -lgdi32 -lopengl32
(Just in case some of the other great explanations didn't quite hit the spot)
The "make" program allows you to use, what are called automatic variables. For every rule that it executes the action for, it parses the shell statements specified in the action, and expands any of these automatic variables that it finds. The variables expand to values in the context of the particular rule being executed at that point.
So, in your case, the rule being executed is:
test: $(SRC)
In this rule, "test" is the target, and whatever $(SRC) expands to, are the dependencies. Now, as "make" parses the following shell statement specified in the action part of the rule,
gcc -o $# $^ $(CFLAGS) $(LIBS)
it recognizes $# and $^ as automatic variables. $# is expanded to the target for the current rule, and $^ is expanded to the dependencies, which is "test" and expansion of $(SRC), respectively. It executes the shell statements after the variables have been expanded. You can see the final expanded version that is executed by watching the output of "make".
$(SRC) will, in turn, expand to the result of the "make" function "wildcard". Keep in mind that the syntax for a function call in "make" is $(function param ...), and is expanded to the result of the function call, in this case the list of files with ".c" as the suffix.
SRC is equal to a wildcard function in gnu make. It is a list of files that match that path. For example, it could be
SRC=a.c b.c
For the rule, it depends on all the source files, and the target is test, so we can expand the rule as follows:
gcc -o $# $^ $(CFLAGS) $(LIBS
gcc -o test $(SRC) $(CFLAGS) $(LIBS)
and then following up by replacing CFLAGS, LIBS and SRC with the correct expansions.
For some documentation on this, take a look at this: http://www.gnu.org/software/autoconf/manual/make/Automatic-Variables.html
Related
I'm currently trying to create a Makefile for a c university project, but reading through the tutorials hasn't quite helped me (also, the makefile is not part of the evaluation process, and we aren't taught how to do it)
My objective is making the makefile automatic, so it automatically creates object files from .c files in src (src/*.c), puts the object files in the bin folder, and links them into an executable in the main directory.
project/
bin/
(object files)
src/
(source files)
executable
Makefile
So far, I've roughly put together this makefile and test source code, but it doesn't work the way I intend it to, which I'll explain how just ahead:
#compiler used
COMPILER = gcc
#flags for individual object file compilation
FLAGS = -Wall -ansi -g
#RELEASE
# -Wall -ansi -O3
#DEVELOPMENT
# -Wall -ansi -g
#source .c files
SOURCE = $(wildcard src/*.c)
#object files created
OBJECTS = $(SOURCE:.c=.o)
OBJECTS = $(SOURCE: src/=bin/)
#executable name
EXECUTABLE = app
############################################################
all: $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(COMPILER) $(FLAGS) -o $(EXECUTABLE) $(OBJECTS)
%.o: %.c
$(COMPILER) $(FLAGS) -c %< -o %#
The result is the following command:
user#user-lenovo:~/Desktop/C Projects/AED/project$ make
gcc -Wall -ansi -g -o app src/main.c src/test.c
Ironically, it works, but really shouldn't. It also defeats the purpose of having a makefile, as everything is compiled again once one change is detected.
First of all, what I noticed is OBJECTS directly copied SOURCE, and didn't substitute .c for .o, or src/ for bin/. I've tried substituting the '=' for ':=' but the result is the same, and I don't quite understand what the difference between them is in the first place. My idea would be src/main.c becoming bin/main.o, for example.
%.o: %.c
$(COMPILER) $(FLAGS) -c %< -o %#
This part is my also failed attempt at generating all the object files individually with a single target. I tried reading up on it, but couldn't figure out how these work: '%<', '%#' or the '%.o' and '%.c'
I do believe it isn't being run at all though, since no object files showed up.
I hope you can help me fix this mess up, thanks in advance!
OBJECTS = $(SOURCE:.c=.o)
OBJECTS = $(SOURCE: src/=bin/)
You're assigning to OBJECTS twice there - the first result gets overwritten by the second which doesn't work. You want to combine them into one statement like this
OBJECTS=$(SOURCE:src/%.c=bin/%.o)
Your next problem is you need to tell make that "bin/whatever.o" is built from "src/whatever.c". Currently it'll look for "whatever.c" in "bin/"
So your recipe for building .o files needs the directories added
bin/%.o: src/%.c
$(COMPILER) $(FLAGS) -c $< -o $#
You also should have $# instead of %# and $< instead of %<
Automatic variables are expanded with the $ prefix, as any other variable, not %.
As your object and source files are in different directories you cannot simply %.o: %.c.
Try:
CC = gcc
CFLAGS = -Wall -ansi -g
OBJECTS = $(patsubst src/%.c,bin/%.o,$(SOURCE))
bin/%.o: src/%.c
$(CC) $(CFLAGS) -c $< -o $#
Note: the standard make variable for the C compiler is CCand CFLAGS for the flags. It is better to use them.
I am trying to compile two c files, calutil.c and calutil.h into one executable. Here is my makefile:
CC = gcc
CFLAGS = -Wall -std=c11 -DNDEBUG
all: caltool
caltool: calutil.o caltool.o
$(CC) $(CFLAGS) calutil.o caltool.o
caltool.o: caltool.c
$(CC) $(CFLAGS) caltool.c -o caltool.o
calutil.o: calutil.c
$(CC) $(CFLAGS) -c calutil.c -o calutil.o
clean:
rm -rf *.o *.out
calutil.c has no main, while caltool.c has a main. I get the error
ld: can't link with a main executable file when I make. What is the cause of this?
The main problem is that some your recipe for linkage is missing the output file, and that your compilation is missing -c.
In case you're using GNU make, the following Makefile would be sufficient to do what you want to do:
CFLAGS:=-Wall -std=c11
CPPFLAGS:=-DNDEBUG
.PHONY: all
all: caltool
caltool: caltool.o calutil.o
.PHONY: clean
clean::
$(RM) *.o
Explanation:
When you're not using target-specific variables, you should use := instead of = to assign variables so that they're expanded at assignment and not at evaluation.
When your Makefile grows and you split it, you might want to have multiple targets called clean which all would be executed. In that case use clean:: instead of clean:.
There's a predefined variable to call rm, it is $(RM) and it includes the -f flag to prevent the Makefile from failing in case one or more of the files to be removed do not exist in the first place.
The pattern for clean should be *.[adios] (that's really easy to remember, adios is Spanish for goodbye) so that it removes intermediate archives (.a when you build your own static libraries), dependency files (.d), preprocessor output (.i) and assembler files (.s) in case you use -save-temps to see what the compiler is doing.
GNU make has built-in rules to compile and link, see http://git.savannah.gnu.org/cgit/make.git/tree/default.c?id=3.81
The built-in rule for compilation calls $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $# $< so you don't need to write your own rule.
The built-in rule for linkage calls $(CC) $(LDFLAGS) $(TARGET_ARCH) $^ $(LOADLIBES) $(LDLIBS) -o $#
Targets which are not files themselves should be declared .PHONY to prevent confusion when a user creates a file with the same name, like all or clean.
I do not see how any of your commands would create a file matching the glob pattern *.out, so I removed that part of the clean rule.
Flags for the preprocessor should go into CPPFLAGS instead of CFLAGS. Preprocessor flags typically are all those -D and -I flags and would also be passed to other tools that use a C preprocessor in the same project, like splint or PC-Lint.
When the Makefile is run, it is looking how to make all, and it finds that for all it has to make caltool. For caltool it finds that it has to first make calutil.o and caltool.o. When it tries to make calutil.o and caltool.o, it finds that it can make them from calutil.c and caltool.c and will do so. Then it will link caltool.o and calutil.o into caltool.
From your naming I guessed that it's caltool.c that contains the main() function. It is helpful to place the object which contains main() first once you use static link libraries.
Edit: Here's some more magic for you. I assume that you have a header file calutil.h which is included by caltool.c to access extern symbols provided by calutil.c. You want to rebuild all objects that depend on these header files. In this case, add the following lines to your Makefile:
CPPFLAGS+=-MMD
-include caltool.d calutil.d
In order to not have the list of objects multiple times, you could add a variable objects like this:
objects:=caltool.o calutil.o
You would then build the application with this rule:
caltool: $(objects)
And include the dependency files like this:
-include $(objects:.o=.d)
In case you keep your working tree "clean", i.e. do not "pollute" it with "alien" code, i.e. you always want to include all .c files in your project, you can change the definition of objects as follows:
sources:=$(wildcard *.c)
objects:=$(sources:.c=.o)
In case you wonder why it is CPPFLAGS (uppercase) but objects (lowercase): it is common to use uppercase for all variables which configure the recipes of rules and control the built-in behavior of make, tools built on top of it, and classic environment variables, and lowercase variables for everything else.
I just removed the .o files from the directory, and edited my makefile to add -c to the caltool.o line.
I'm trying to create a Makefile for my C program in Raspbian (Raspberry Pi).
My program consists of a bunch of .c and .h Files. I've looked at countless Makefiles, but I just don't unterstand how it works with multiple files. There are always .o files in the Makefile but as I understand object files are the result of compiling, so I dont have any o. Files as I am trying to compile my .c Files.
Please explain to me how this works.
Edit:
Thank you. So I tried this and it starts compiling but there are errors 'multiple definition'. Example:
These are my Files:
main.c main.h
calibration.c calibration.h
file.c file.h
frame.c frame.h
gamepad.c gamepad.h
gpio.c gpio.h
uart.c uart.h
types.h
this is my makefile:
all: main
main: main.o calibration.o file.o frame.o gamepad.o gpio.o uart.o
%.o: %.c
gcc -c -std=c99 -Wall $< -o $# -lncurses
Where can i put 'types.h'?
With every file I get errors 'multiple definitions'
A very simple but typical makefile could look like this
SOURCES = source1.c source2.c source3.c
OBJECTS = $(SOURCES:%.c=%.o)
TARGET = myExecutable
$(TARGET): $(OBJECTS)
gcc $^ -o $#
%.o: %.c
gcc -c $< -o $#
The complicated parts:
SOURCES = source1.c source2.c source3.c This is a variable definition, it assigns the string "source1.c source2.c source3.c to the variable SOURCES.
$(SOURCES:%.c=%.o) This is a shorthand for the patsubst text function. It takes all text from the $(SOUCES) variable, and replaces the pattern %.c with %.o, i.e. it takes e.g. the string source1.c and replace it with source1.o.
$(TARGET): $(OBJECTS) This makes myExecutable depend on all object files, meaning if one object file is modified then the command in the rule will be executed.
gcc $^ -o $# This calls the gcc command, passing all dependencies ($^) as arguments (that is, all object files), and tells gcc to output a file with the name of the target ($#).
%.o: %.c This is the rule that makes object files depend in their source file. So if you have source1.c then source1.o will depend on that source file.
gcc -c $< -o $# This is the command that compiles the source file (the first dependency, $<) to an object file (with the -c option) and name it as the target of the rule ($#).
Also note that if you invoke make without a specific target, then the first rule will be selected. In the case of the above makefile, it will be the $(TARGET): $(OBJECTS) rule which will make sure that all object files are build from the source files, and then link the object files into the resulting executable.
The basic syntax of a make rule is:
target … : prerequisites …
recipe
…
…
On the left of the semicolon are the targets. The targets are your object files(.o). On the right of the semicolon are the files that you will need to create this file. Those files are the source files(.c).
Lets give a basic example of what such a rule could look like.
%.o: %.c
gcc -c $< -o $#
The % sign is a wildcard. %.o means everything that ends with .o. So, if you want to make an object file, you can say make file.o, and make will try to find a rule with which it can make this target. This happens to be the rule I just showed as an example, because file.o matches %.o.
Then the recipe. This is what will be executed. Usually it's about invoking the compiler(gcc), and feeding it the source file to generate the object file. That's what we do with gcc -c $< -o $#. The $< and $# mean target and prerequisites respectively.
So, what happens when you 'just' want to build your program? You usually will type make, and it will build. The default rule that's used when you type make, is all. So, if you make a rule about all, then you can specify what files you want to create to build your program. Example of such a rule:
all: main
Then, when make is invoked, it will find that rule and finds out it needs main. To create main you need another rule:
main: file.o
This rule says that to build main, you need file.o. So, when you put all of the example rules together you get this:
all: main
main: file.o
%.o: %.c
gcc -c $< -o $#
Note that you can specify more than one file, so instead of file.o, you can say file.o main.o other_file.o etc. Every prerequisite that you specify will be made, if they can find a rule to make it.
I'm trying to create a makefile which would have as little command repetition as possible. Basic idea is to have variable name assigned at the target, like so:
CC = gcc
CFLAGS = -std=c99 -pedantic-errors -Wall
some_target:
P = some_target
some_other_target:
P = some_other_target
...
#common compilation command
$(CC) $(CFLAGS) $(P).c -o $(P).o
So there's only one compilation command which receives variable P which is unique for each target. Obviously example above doesn't work, what do i need to change to make it correct?
This is already built in. The variable $< expands to the first dependency and $^ expands to all dependencies. There is also $? which expands to only those dependencies which are newer than the target. See the documentaion for a full list.
Make already knows how to compile a .c file into an .o file, but if you want to see how it's done, the pattern looks a bit different from yours.
some_command.o: some_command.c
other.o: other.c
%.o: %.c
$(CC) $(CCFLAGS) $< -o $#
I was compiling some C code for an assignment and I ran "make codeFile", where "codeFile" was the name of my C program, and even though I didn't have a makefile, an executable was created, and it ran and worked correctly.
Does anyone know why this worked? Why does make compile something even if I don't have a makefile? The only reference I could find was this:
http://daly.axiom-developer.org/TimothyDaly_files/class5/node5.html
Make has an internal database with implicit rules. You can use make -p to list them. Also make -d will tell you which rules are being applied, so that would help you discover which implicit rules are being used in this case.
Make has several pre-defined implicit rules. In particular, in your case, it uses two such rules when trying to determine what to do for the target codeFile:
%: %.o # Link object file
$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)
%.o: %.c # Compile C source code
$(CC) $(CPPFLAGS) $(CFLAGS) -c
Using the make command without makefiles?
make has implicit rules that work as defaults unless you override them.
According to the make man page:
make -p -f/dev/null
will list all of the implicit rules (and relevant environment variables) without attempting to actually remake files.
To demonstrate the usage, I ran make in Cygwin, which gave me an exe file. Note no .c on the name passed to make:
$ ls
hello.c
$ make hello
cc hello.c -o hello
$ ls
hello.c hello.exe
I also ran this in Ubuntu Linux, and my result was nearly the same as above, but the .exe extension was not there, instead I had the plain hello executable:
$ ls
hello.c hello
Step by step derivation
I believe the relevant pieces of the make implicit rules are as follows:
CC = cc
cc is aliased to CC
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
a LINK format is created, where the flags will be empty, and the TARGET_ARCH variable is also empty (to allow users to set values for various target architectures.) Then we have:
%: %.c
# recipe to execute (built-in):
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $#
The ^ variable is the prerequisite, hello.c. The other variables are empty. These are followed by the -o flag and the target name. The empty variables explain the extra spaces in the command make ran:
cc hello.c -o hello
And the %: %.c matched the target given to make with the filename of the same target name ending in .c, which caused the recipe to execute.