I have a makefile
jumbo: objs/jumbo.o objs/utils.o
objs/%.o: %.C
$(CXX) $(CFLAGS) $(CPPFLAGS) -c -o $# $<
The result of the compile
g++ jumbo.C objs/jumbo.o objs/utils.o -o jumbo
objs/jumbo.o:jumbo.C:(.text+0x0): multiple definition of `main'
/tmp/ccwEFt9o.o:jumbo.C:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
make: *** [<builtin>: server] Error 1
if I replace the definition of jumbo
jumbo: jumbo.C objs/utils.o
the problem goes away but the object file is not put away in the objs directory
And I don't know whether it is recompiling jumbo or not when it should only be relinking
You haven't defined any recipe for building the target jumbo. Because of that, make looks for a built-in rule and there is one that knows how to build a file X from a file X.C. Make looks at the directory and lo and behold, there's an X.C (jumbo.C) that exists, so make chooses to use that built-in rule. The built-in rule is:
%: %.C
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $#
so, since jumbo depends on objs/jumbo. and objs/utils.o directory plus the jumbo.C from the default implicit rule, you get all three on the command line.
To fix this just define your own recipe for creating jumbo:
jumbo: objs/jumbo.o objs/utils.o
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $#
Related
I have a line line in make file for compiling a c program, which goes like this
$(CC) -c -o $# $< $(CFLAGS). I have to modify a particular line in code every time and compile again. Modification is just an argument to a function. I have the argument in one file and i use sed utility to modify my c source and then compile. I want to see which of the arguements leads to successful compilation. I tried to use this $(CC) -c -o $# $< $(CFLAGS) ; echo $? >status where I was hoping if compilation was successful status file would have an entry 0. But i see the source file name in status file. I came to know that $? is also a make automatic variable. How can i read the shell variable $? within makefile ? I have tried using $(CC) -c -o $# $< $(CFLAGS) ; echo $$? >status and $(CC) -c -o $# $< $(CFLAGS) ; echo $(shell echo $?) >status without getting correct results.
The version
echo $$? > status
definitely works for me. What OS are you using? What are the incorrect results when using $$??
If you are on Windows, there is no $?, you might want ot use %errorlevel% instead.
I have a directory with dozens of source and header files. Is there a better or cleaner way than the following %.o target for make to detect changes to header files? When the object is compiled, g++ is invoked with both the .cc and .h files which doesn't seem right, it should find the .h file automatically.
%.o: %.cc %.h
g++ -c $^
OBJECTS=headless-driver.o config.o simplefm2.o emulator.o basis-util.o objective.o weighted-objectives.o motifs.o util.o
learnfun : $(OBJECTS) learnfun.o
g++ $^ -o $#
%.o: %.cc %.h
g++ -c $^
You are specifying $^ which expands to all dependencies. If you just want the first dependency on the Gcc command line, use $< instead.
I'm trying my hand at using recursive make to eliminate things like having multiple CFLAGS variables, one for each target. There is only one level of recursion, there is no crazy directory tree traversal happening here. I just want to dump my object files into their target specific folders.
So far I have come up with something that is really elegant (edit: alright it's more elegant than the single-makefile solution i had from before. Which had way too much repetition!) but unfortunately does not work.
I think that by posting the format here it will be apparent what it is that I am trying to do.
# ./makefile
.PHONY: all clean
export CC = g++
export INCLUDE = -I ../include/
export SRC = Main.cpp Graphics.cpp Thread.cpp Net.cpp Otherstuff.cpp
export LINKEROPT = -lglew32 -lopengl32 -lsdl -lws2_32 -lglu32 -lmorelibraries
test:
$(MAKE) -f make.unittest
all:
$(MAKE) -f make.unittest
$(MAKE) -f make.debug
$(MAKE) -f make.release
clean:
-rm -rf build_* *.exe
# I am on windows so the targets are .exe's
Here is the file make.debug:
### sub-makefile for the debug build target. Contains target specific build settings.
DIRNAME = build_debug
TARGETNAME = program_debug
TARGETDESCR = DEBUG
CFLAGS = -Wextra -Wall -O0 -g3 -DDEBUG
### EVERYTHING AFTER THIS POINT IS A TEMPLATE
# my goal is to have as much of my makefile code being "reusable" as possible
# so that I can easily add targets.
OBJ = $(patsubst %.cpp,$(DIRNAME)/%.o,$(SRC))
DEPS = $(patsubst %.cpp,$(DIRNAME)/%.d,$(SRC))
-include $(DEPS)
# default behavior. Set up the build directory. Then build the debug target.
all: $(DIRNAME) $(TARGETNAME)
# this is the build dir
$(DIRNAME):
mkdir $(DIRNAME)
$(DIRNAME)/%.o: %.cpp
#echo -e "Compiling for $(TARGETDESCR): $< --> $#"
$(CC) $(CFLAGS) $(INCLUDE) -c $< -o $#
#echo -e "Generating dependencies: $< --> $(patsubst %.o,%.d,$#)"
$(CC) $(CFLAGS) $(INCLUDE) -MM -MT $# -MF $(patsubst %.o,%.d,$#) $<
# I realize there is a way to generate the deps while compiling in one pass
# but I'll figure it out later
$(TARGETNAME): $(OBJ)
#echo -e "Linking $(TARGETDESCR): $#.exe"
$(CC) -L ../lib/win32/ -o $# $(OBJ) $(LINKEROPT)
As you can see, I can very quickly add a new build target with its own set of CFLAGS by copying over the sub-makefile and lightly modifying it, and then adding a few entries to the main makefile.
So the problem here is that it doesn't recognize changes in files. Only when I edit Main.cpp will it recompile build_debug/Main.o. I'm really unsure about where I can start to figure out what's incorrect.
I've created a monster.
When I suggested recursive make in that other post it was to deal with a specific -- and very strange -- problem of inclusion. I do not subscribe to the dogma that recursive make is pure evil, but it does have disadvantages, and should not be used as a cure-all.
First, let's eliminate a bad (and ongoing) source of redundancy. In you main makefile, instead of
$(MAKE) -f make.debug
use
$(MAKE) -f makefile.sub DIRNAME = build_debug TARGETNAME = program_debug TARGETDESCR = DEBUG CFLAGS = -Wextra -Wall -O0 -g3 -DDEBUG
where makefile.sub is the "template" part of your various sub-makefiles. I know that doesn't look like an improvement, but this way you have only one sub-makefile, not N. (I also think you're using too many target-specific variables, but we can discuss that later.)
Once you're comfortable with this, you can use target-specific variables within makefile.sub, so that in the main makefile you can replace
all:
$(MAKE) -f makefile.sub DIRNAME=build_unittest ...
$(MAKE) -f makefile.sub DIRNAME=build_debug ...
$(MAKE) -f makefile.sub DIRNAME=build_release ...
with
all:
$(MAKE) -f makefile.sub unittest debug release
It's not clear to me what problem you're having with recognizing changes in files (when should Make rebuild build_debug/Main.o, if Main.cc hasn't changed?), but it's probably a direct consequence of using make recursively (see "disadvantages", above) and we can probably fix it without too much grief.
EDIT:
In your sub-makefile, put the all rule before the -include line, so that it will be the default rule. When you call $(MAKE), you don't specify a target, so Make chooses the default target, which is (usually) whichever one comes first. The contents of the %.d files have the form of rules, so if you include them first, one of them (i.e. build_debug/Main.o: Main.cpp) will win.
I have a Makefile that looks like this
CXX = g++ -O2 -Wall
all: code1 code2
code1: code1.cc utilities.cc
$(CXX) $^ -o $#
code2: code2.cc utilities.cc
$(CXX) $^ -o $#
What I want to do next is to include clean target so that every time
I run make it will automatically delete the existing binary files of code1 and code2 before creating the new ones.
I tried to put these lines at the very end of the makefile, but it doesn't work
clean:
rm -f $#
echo Clean done
What's the right way to do it?
The best thing is probably to create a variable that holds your binaries:
binaries=code1 code2
Then use that in the all-target, to avoid repeating:
all: clean $(binaries)
Now, you can use this with the clean-target, too, and just add some globs to catch object files and stuff:
.PHONY: clean
clean:
rm -f $(binaries) *.o
Note use of the .PHONY to make clean a pseudo-target. This is a GNU make feature, so if you need to be portable to other make implementations, don't use it.
In makefile language $# means "name of the target", so rm -f $# translates to rm -f clean.
You need to specify to rm what exactly you want to delete, like rm -f *.o code1 code2
By the way it is written, clean rule is invoked only if it is explicitly called:
make clean
I think it is better, than make clean every time. If you want to do this by your way, try this:
CXX = g++ -O2 -Wall
all: clean code1 code2
code1: code1.cc utilities.cc
$(CXX) $^ -o $#
code2: code2.cc utilities.cc
$(CXX) $^ -o $#
clean:
rm ...
echo Clean done
(disclaimer: I am used to scons ... I am somewhat unexperienced with make)
Context: I am using Eclipse CDT which generates makefiles.
Let's say I have a project directory 'lib' and 2 build configurations 'Debug' and 'Release'. Eclipse CDT gracefully generates a makefile for each build configuration. The said makefiles end-up residing in 'Debug' and 'Release' folders.
Now, what I want to do is have a makefile in the folder 'lib' which calls the makefiles 'Debug/makefile' and 'Release/makefile'.
How do I do that?
I want to be able to launch 'make' in the folder 'lib' and both configurations would be called with the specified target(s).
Solution
Based on all the great input gathered here, I devised the following:
MAKE=make
BUILDS=Release Debug
TARGETS=all clean
$(TARGETS):
#for b in $(BUILDS) ; do $(MAKE) -C $$b $# ; done
$(BUILDS):
#for t in $(TARGETS) ; do $(MAKE) -C $# $$t ; done
%:
#for b in $(BUILDS) ; do $(MAKE) -C $$b $# ; done
depends on what is "calls". You want to either
include $(BUILD)/Makefile
or
$(MAKE) -C $(BUILD) $#
or some such. I'd guess you want the latter. Maybe something like
release debug:
$(MAKE) -C $#
You get the idea.
More examples:
BUILDS=release debug
TARGETS=all clean
$(TARGETS):
for b in $(BUILDS) ; do $(MAKE) -C $$b $# ; done
$(BUILDS):
for t in $(TARGETS) ; do $(MAKE) -C $# $$t ; done
Since you mention "the specified target(s)", I suggest:
%:
$(MAKE) -C Debug $#
$(MAKE) -C Release $#
If that's too general, you can replace the % with $(TARGETS), where TARGETS is something you define, a list of all the things you'd ever want to do this with.
all: release debug
release:
$(MAKE) -C ../Release
debug:
$(MAKE) -C ../Debug
I'm assuming they're all on the same level. The path must be from where you call Make.
Have different targets that invoke the makefile in the two directories.
all: debug product
debug:
$(MAKE) -f debug/Makefile
product:
$(MAKE) -f product/Makefile