This is my first attempt to create a make-file for compiling. I'm working on a project where I want to divide files under compiling, sow i have 3 folders: src, bin and header. Today I compile with the command gcc file1.c file2.c file3.c -lncurses
How can I write a makefile to achieve this ?
This will do it:
bin/myBinaryName: file1.c file2.c file3.c
gcc $^ -Iheader -lncurses -o $#
vpath %.c src
There are more sophisticated approaches than this, but I suspect that you are taking the same course as the other newcomers who have asked very similar questions over the past couple of weeks.
If you want a more basic introduction, or a more sophisticated makefile, you can try a different question.
EDIT:
Let's try something simpler. Write this makefile (and name it makefile):
all:
echo hello world
Note that the whitespace before "echo" is a TAB. Now try make on the command line. What happens?
Related
SOURCE=a.c b.c c.c
ASM=$(patsubst %.c,%.s, $(SOURCE))
all:%.o
gcc -o test $^
$(ASM):%.c
gcc -S -o $# $<
%.o:%.s
gcc -c -o$# $<
I want to generate assembly code (.s) first, then compile the assembly code to object (.o), then link them.
But it seems above makefile code does not work. What is the correct code?
When asking questions, does not work is never very useful... if it worked you probably wouldn't be asking a question! :-) Instead you should always show the command you ran and the output you received (or at least the failing part of the output if it's long). Please cut and paste the actual text rather than paraphrasing messages. Also, including the version of the make program you're using (make --version) and the platform you're running on is often helpful.
Luckily this time we can figure out the problem without this information:
This:
$(ASM):%.c
gcc -S -o $# $<
where ASM is a.s b.s c.s, is not a pattern rule because the targets don't contain a pattern character %. That means the prerequisite %.c is not treated as a pattern, but as an actual file name, literally %.c which obviously doesn't exist.
Similarly, this:
all: %.o
has the same problem: all is a target, so this depends on the literal file named %.o which doesn't exist, and can't be created.
Also as a general rule every recipe that creates a target must create the actual target you told make it would, so this all rule is wrong because the target name is all but the recipe creates the target test.
Finally, it's a very bad idea to name your program test because test is a common UNIX program and a shell built-in, so if you run test it won't do the right thing (if you run ./test it will work).
You want to have all depend on the program you want to build, say mytest, and mytest should depend on the actual .o files:
all: mytest
mytest: $(SOURCE:.c=.o)
gcc -o $# $^
Next, you need to define a pattern rule that knows how to create an assembly file from a source file:
%.s : %.c
gcc -S -o $# $<
That, along with your other pattern rules, is all you need: make will figure it all out from that.
Finally, make has a built-in rule that tells it how to build object files directly from source files. It's best to get rid of this to force make to use your rules; add this to your makefile to delete it:
%.o : %.c
I am working on a makefile on OS X and I'm having issues. I've made everything as I am supposed to (I think) but only part of it is working. When I try :
make file1
or:
make file2
everything seems fine but when I try :
make all
or:
make clean
I get the typical :
*** No rule to make target
Here's the code, I hope you can spot the issue(s) :
CC = gcc
CFLAGS=-Wall
FILES=file1 file2
all: $(FILES)
file1: file1.c
$(CC) $(CFLAGS) file1.c -o file1
file2: file2.c
$(CC) $(CFLAGS) file2.c -o file2
clean:
$(RM) $(FILES)
Cheers !
Transferring comments into an answer, mainly so the question can be closed.
There's no obvious reason why the syntax shown would cause that problem, so I suspect that make file1 is working without any makefile and coming up with a default rule to do the compilation (and probably doesn't use the -Wall option when compiling).
What's the name of the makefile you created?
The makefile is named makefile, and you are indeed right: -Wall isn't used (I just noticed).
That's curious. Take a close look at the name: ls m* | od -c. See if the letters are what you expect, and there's no trailing space at the end of the name or anything untoward like that.
But the 'no -Wall' observation practically confirms that the trouble is with the name of the makefile, though it isn't yet obvious why it is not working. You could try make -f makefile all and see whether that makes any difference. If the name is wrong, you should get told that it can't open the makefile.
I tried remaking a makefile from scratch containing exactly the same information and it runs smoothly. You were definitely right about the name issue.
That sort of problem is bizarre and confusing — it was sensible to get help.
I am new to linux development.
I wrote a project using MPI and cuda. When
it gets bigger and bigger, I realize that I
need a Makefile now. So I learned how to write
one. The Makefile works, but will only compile
cpp files even if I have both of the following
lines in my Makefile:
.cpp.o:
$(CC) $(CCFLAGS) $<
.cu.o:
$(NVCC) $(CCFLAGS) $<
Any idea why this is happening? Thanks.
UNDERSTANDING MAKE
Make is all about generating missing files.
If you have TWO rules that generate the SAME file upon existence of a source then the first one in make's list that actually has a source file present will get invoked. So for instance if you have the rules:
.c.o:
$(CC) -o $# -c $<
.cpp.o:
$(CXX) -o $# -c $<
and you have two files, foo.c and bar.cpp then you can type:
$ make foo.o
it will use the first rule... and when you type
$ make bar.o
it will use the second rule.
Now suppose you have TWO files foo.c and foo.cpp
Here make has to make a choice as to which takes precedence. Make uses suffixes of files intimately for its build rules. What is considered a suffix is controlled by the .SUFFIXES directive.
The .SUFFIXES directive has a default built-in value that defines common suffixes such as .c .cpp .cc .o etc. in a particular order. If we want to change the order of precedence we clear that out with a blank line in Makefile i.e.:
.SUFFIXES:
and then follow it with our definition:
.SUFFIXES: .cpp .c .o
if you don't blank the line out, then make just appends the listed suffixes to its current list, that way multiple makefiles can simply add new suffixes without worrying about breaking each other.
Now since the .cpp is before .c the .cpp.o rule will take precedence (in case foo.cpp and foo.c are both present)
NOTE: Yes there is a "." before the words SUFFIXES and yes it is all capital letters.
Try to play with this Makefile to see the effects:
.SUFFIXES:
.SUFFIXES: .cpp .c .o
.c.o:
echo Compiling C
.cpp.o:
echo Compiling CPP
Make is very very powerful, and quite well documented so well worth the read. GNU make, which is probably the strongest implementation with amazing extensions has made me a lot of money in the past :-) enjoy the experience.
Your rule is wrong, you want something like this:
%.o : %.cu
$(NVCC) $(CCFLAGS) $< -o $#
That's assuming the command line you need to execute is something like
nvcc foo.cu -o foo.o
Otherwise, edit to suit.
I'm sure this is a totally normal thing to do, but I can't figure out how to get make to do this.
I have a compiler that generates make dependencies of the usual form:
M/A.o : M/A.hs
M/B.o : M/A.o
So I write a rule to compile %.hs into %.o, add a rule to link the binary, include the dependencies file, and all is well. But I want to have several binary targets with different flags. E.g. I want build/test built with -DTESTING and build/profile built with -prof. So I need to keep the .o files in a separate tree, where they will be compiled with special flags.
The straightforward way I can think of would be to have dependencies that look something like this:
build/test/M/A.o : M/A.hs
build/test/M/B.o : build/test/M/A.o
build/profile/M/A.o : M/A.hs
... etc.
And then rules so that %.hs to build/test/%.o compiles with -DTESTING, etc. I think this would work, but it's clumsy, means preprocessing the deps file to add all that build/whatever/ prefix stuff, and would multiply its size by however many kinds of builds.
VPATH appears to be designed for this sort of thing and my idea was that I could set the VPATH and compiler flags depending on the target, and it almost works, but:
%.o: %.hs
#mkdir -p build/M
cp $< build/$#
VPATH = build
main: M/A.o M/B.o
cat $^ >$#
M/A.o : M/A.hs
M/B.o : M/B.hs
The first time the main target wants to run 'cat M/A.o M/B.o >main' which seems contrary to the gnu make documentation that says $^ should include the include the VPATH directory in which the dependency was found. Curiously, if I remove 'main' and make again, this time it uses the correct path. This is GNU make, 3.81.
What's going on here? Is there a better way to build with different flags? VPATH seems like a clumsy tool, surely there is a better way?
Make is working correctly. It tries cat M/A.o M/B.o >main the first time because it can't find the prerequisites it needs, but it knows a rule for M/A.o' andM/B.o(<em>not</em>build/M/A.o' and build/M/B.o) and expects that that is what the rule will produce. If you remove main and try again, it will find build/M/A.o' andbuild/M/B.o` via VPATH.
Let's modify this makefile in stages. First we change the VPATH so that it can find the .hs files (Make is good at using things there to build things here, not vise-versa, and that's what VPATH is good for), and change the rules slightly:
build/%.o: %.hs
cp $< $#
VPATH = M
main: build/A.o build/B.o
cat $^ > $#
Now for the different object directories.
build/test/%.o build/project/%.o: %.hs
cp $< $#
VPATH = M
test: build/test/A.o build/test/B.o
cat $^ > $#
project: build/project/A.o build/project/B.o
cat $^ > $#
Then we simplify those last two rules, so that it's easy to add more object files and binary targets:
OBJECTS = A.o B.o
test: $(addprefix build/test/,$(OBJECTS))
project: $(addprefix build/project/,$(OBJECTS))
test project:
cat $^ > $#
Now for the different compiler flags:
build/test/%.o: FLAGS += test_flags
build/project/%.o: FLAGS += proj_flags
build/test/%.o build/project/%.o: %.hs
#echo building $# from $^ using flags $(FLAGS)
cp $< $#
Finally the dependencies. This is a little tricky. Suppose you want the dependency B.o : A.hs to apply to however many object you have. This is one approach:
OBJECT_PATHS = build/test/ build/project/
# The following is from the included file generated by the compiler
$(addsuffix B.o,$(OBJECT_PATHS)) : A.hs
To generate lines like that, I'd pipe the raw lines (e.g. B.o: A.hs) through sed 's/\(.*\):\(.*\)/\1:\2/', and note that if you want to put this in a makefile command, don't forget to double the $ signs to preserve them for the shell.
I know that's a lot to absorb. Take it one step at a time and let us know how it works out.
If you haven't solved your problem by now or are experiencing further problems, best give the autotools (automake and autoconf) a chance. They'll quickly build you a Makefile that supports more configurable and flexible out-of-tree builds.
I have a directory in which I keep adding different C++ source files, and generic Makefile to compile them. This is the content of the Makefile:
.PHONY: all clean
CXXFLAGS = -pipe -Wall -Wextra -Weffc++ -pedantic -ggdb
SRCS = $(wildcard *.cxx)
OBJS = $(patsubst %.cxx,%.out,$(SRCS))
all: $(OBJS)
clean:
rm -fv $(OBJS)
%.out: %.cxx
$(CXX) $(CXXFLAGS) $^ -o $#
NOTE: As is obvious from above, I am using *.out for executable file extensions (and not for object file).
Also, there are some files which are compiled together:
g++ file_main.cxx file.cxx -o file_main.out
To compile such files, until now I have been adding explicit rules in the Makefile:
file_main.out: file_main.cxx file.cxx
file.out: file_main.out
#echo "Skipping $#"
But now my Makefile has a lot of explicit rules, and I would like to replace them with a simpler implicit rule.
Any idea how to do it?
First, this method of compiling several source files directly into an executable is not a terribly good idea. The more common compile-then-link approach will save a lot of unnecessary compilation.
That said, the way to replace many explicit rules with a simpler rule depends on what the explicit rules have in common. You already have a pattern rule:
%.out: %.cxx
$(CXX) $(CXXFLAGS) $^ -o $#
and if all you want to do is add another source file to a particular target, you don't have to do this:
g++ file_main.cxx file.cxx -o file_main.out
you can get the effect just by adding a prerequisite (in a line by itself):
file_main.out: file.cxx
If you have several targets with that pattern, you can use a pattern rule:
file_main.out another_main.out a_third_main.out: %_main.out : %.cxx
If you have many such targets, you can use a variable:
MAIN_THINGS = file another a_third a_fourth and_yet_another
MAIN_TARGETS = $(addsuffix _main.out, $(MAIN_THINGS))
$(MAIN_TARGETS): %_main.out : %.cxx
And you can add other patterns for other target sets, even overlapping sets. Does that cover your situation?
It seems that you are putting the source code for multiple different programs in the same folder, and this is really the source of your problems. If you separate the source code for your libraries and programs into separate folders (or, better yet, separate projects), then you can skirt this issue by depending on all source files in the given folder. When you have everything intermixed, it is necessary to be explicit.
That said, if your dependencies have consistent, predictable names, then it is possible to eliminate this redundancy by using the eval function. For example, based on the example above:
#
# I'm going to use standard file extensions here,
# slightly deviating from your conventions. I am also
# assuming that there is a variable named PROGNAMES,
# which gives a list of all the programs to be built.
#
define ADD_EXECUTABLE
$(1): $(1).o $(1)_main.o
$(LINK.cc) $(1).o $(1)_main.o -o $(1)
endef
$(foreach progname,$(PROGNAMES),$(eval $(call ADD_EXECUTABLE,$(progname))))
Also, just a few suggestions... you should append to CXXFLAGS rather than overwrite it and you would be better off using standard file extensions (".cpp" for C++ source files, ".o" for object files, no extension for executables). See my Makefile tutorial for tips on making things easier with Make (no pun intended).