Debugging GNU make
Is there a command line way in make to find out which of the prerequisites of a target is not updated?
isn’t there like a verbose mode? And can’t you just enter in some echo debugging at each target to figure that out?
7 Answers 7
should give you more than enough information to debug your makefile.
Be warned: it will take some time and effort to analyze the output but loading the output into your favorite editor and doing searches will assist a lot.
You can greatly reduce the amount of debugging output if you specify the specific target you’re interested in. So if you’re only interested in the dodgy target, instead of just make -d which may make a hundred different things, try:
(assuming you have a clean target of course).
The make —debug is identical to make -d but you can also specify:
- a for all debugging (same as make -d and make —debug ).
- b for basic debugging.
- v for slightly more verbose basic debugging.
- i for implicit rules.
- j for invocation information.
- m for information during makefile remakes.
It looks like make —debug=b is the best option for what you need, as shown in the following transcript:
pax@paxbox> cat makefile c:a b touch c pax@paxbox> touch a b ; make touch c pax@paxbox> make make: 'c' is up to date. pax@paxbox> touch a ; make --debug=b GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. Blah, blah, blah. Reading makefiles. Updating goal targets. Prerequisite 'a' is newer than target 'c'. Must remake target 'c'. touch c Successfully remade target file 'c'. Another suggestion that if you want to get rid of built-in implicit rules, you may use -r flag alongside mere -d .
Are you looking for Make’s «dry run»? It will print out what make is doing without actually doing so, allowing you to see what happens.
The flag is -n , use it like make -n .
This is my favourite, -d is much too verbose (even —debug=b ). Especially if you’re stuck with recursive make (ugh!).
What I usually do is not go using -d as previous answerers said.
- Use -p to print the database, to see what rules have been created. This is handy if you have second expansion rules and are creating rules on the fly, especially recursive make.
- Heavy use of $(info) function.
- Use the tips and trick described in this DrDobbs article Debugging Makefiles
Below is some code I’m using for printing out values:
define pv $(info $(1) [$(origin $(1))] : >|$($(1))|<) endef define pva $(foreach t,$(1),$(call pv,$(t))) endef define itemizer $(foreach t,$($(1)),$(info $(t))) endef There's also GNU make with a debugger and better trace/error output: Remake
Both of these, while still relevant, are a bit old.
Your question is a little unclear. If you want to see which prerequisite files have not been modified recently, use ls -l to see their modification time. If you want to see what make is doing, try this:
# Make will announce when it is making this target, and why. sometarget: preq1 preq2 preq3 @echo making $@ @echo The following preqs are newer than the target: $? do_things
Not really a command-line solution but useful nonetheless. You could possibly make it command-line based by only doing the echos only if an env-var is set.
Few times I've also used this (old but still working) interactive make debugger by John Graham-Cumming
i am using make gnu make templates to define the make rules per target;
this feature is useful when you have a make system that includes a core makefile to generate all rules per project type; if it says to do a shared library then it writes the rules to compile a shared library; etc. for other types of targets.
in this example: if you add SHOW_RULES=1 to the make command line it also shows the text of the rules that are generated by the PROGRAM_target_setup_template ; along with generating the rules themselves (with eval).
# this one defines the target for real $(foreach prog, $(TARGETS), $(eval $(call PROGRAM_target_setup_template,$(prog)))) ifneq "$(SHOW_RULES)" "" $(foreach prog, $(TARGETS), $(info $(call PROGRAM_target_setup_template,$(prog)))) endif - $(call . ) invokes the template
- $(info . ) prints the result of template substitution; ( eval would have invoked parsing of the output and addition to the current make file )
How can I configure my makefile for debug and release builds?
I have the following makefile for my project, and I'd like to configure it for release and debug builds. In my code, I have lots of #ifdef DEBUG macros in place, so it's simply a matter of setting this macro and adding the -g3 -gdwarf2 flags to the compilers. How can I do this?
$(CC) = g++ -g3 -gdwarf2 $(cc) = gcc -g3 -gdwarf2 all: executable executable: CommandParser.tab.o CommandParser.yy.o Command.o g++ -g -o output CommandParser.yy.o CommandParser.tab.o Command.o -lfl CommandParser.yy.o: CommandParser.l flex -o CommandParser.yy.c CommandParser.l gcc -g -c CommandParser.yy.c CommandParser.tab.o: CommandParser.y bison -d CommandParser.y g++ -g -c CommandParser.tab.c Command.o: Command.cpp g++ -g -c Command.cpp clean: rm -f CommandParser.tab.* CommandParser.yy.* output *.o Just to clarify, when I say release/debug builds, I want to be able to just type make and get a release build or make debug and get a debug build, without manually commenting out things in the makefile.
The executable target violates the golden rule of makefiles: every target should update the file naming the target, in your case "executable".
7 Answers 7
CXXFLAGS = -g3 -gdwarf2 CCFLAGS = -g3 -gdwarf2 all: executable debug: CXXFLAGS += -DDEBUG -g debug: CCFLAGS += -DDEBUG -g debug: executable executable: CommandParser.tab.o CommandParser.yy.o Command.o $(CXX) -o output CommandParser.yy.o CommandParser.tab.o Command.o -lfl CommandParser.yy.o: CommandParser.l flex -o CommandParser.yy.c CommandParser.l $(CC) -c CommandParser.yy.c Remember to use $(CXX) or $(CC) in all your compile commands.
Then, 'make debug' will have extra flags like -DDEBUG and -g where as 'make' will not.
On a side note, you can make your Makefile a lot more concise like other posts had suggested.
You should never change CXX or CC within a Makefile or BadThingsMayHappen (TM), those contain the path and/or name of the executables to run. CPPFLAGS, CXXFLAGS and CFLAGS serve this purpose.
This advice is poor because it mixes debug and non-debug object files, so that one ends up with a corrupted build.
@MaximEgorushkin how to fix that? I came across this problem recently. I have a debug executable build, that was linked with release object files. Only solution so far was to declare debug and release targest phony
@MauriceRandomNumber Build debug/release into its own folders. Example: stackoverflow.com/a/48793058/412080
This is the WORST possible workaround and unfortunately was accepted by the OP! I see this mess showing up in student projects, and my guess is that some of them copy pasted from this "accepted" answer. PLEASE DON'T DO IT THIS WAY! See the other good solutions here.
This question has appeared often when searching for a similar problem, so I feel a fully implemented solution is warranted. Especially since I (and I would assume others) have struggled piecing all the various answers together.
Below is a sample Makefile which supports multiple build types in separate directories. The example illustrated shows debug and release builds.
- separate project directories for specific builds
- easy selection of a default target build
- silent prep target to create directories needed for building the project
- build-specific compiler configuration flags
- GNU Make's natural method of determining if project requires a rebuild
- pattern rules rather than the obsolete suffix rules
# # Compiler flags # CC = gcc CFLAGS = -Wall -Werror -Wextra # # Project files # SRCS = file1.c file2.c file3.c file4.c OBJS = $(SRCS:.c=.o) EXE = exefile # # Debug build settings # DBGDIR = debug DBGEXE = $(DBGDIR)/$(EXE) DBGOBJS = $(addprefix $(DBGDIR)/, $(OBJS)) DBGCFLAGS = -g -O0 -DDEBUG # # Release build settings # RELDIR = release RELEXE = $(RELDIR)/$(EXE) RELOBJS = $(addprefix $(RELDIR)/, $(OBJS)) RELCFLAGS = -O3 -DNDEBUG .PHONY: all clean debug prep release remake # Default build all: prep release # # Debug rules # debug: $(DBGEXE) $(DBGEXE): $(DBGOBJS) $(CC) $(CFLAGS) $(DBGCFLAGS) -o $(DBGEXE) $^ $(DBGDIR)/%.o: %.c $(CC) -c $(CFLAGS) $(DBGCFLAGS) -o $@ $< # # Release rules # release: $(RELEXE) $(RELEXE): $(RELOBJS) $(CC) $(CFLAGS) $(RELCFLAGS) -o $(RELEXE) $^ $(RELDIR)/%.o: %.c $(CC) -c $(CFLAGS) $(RELCFLAGS) -o $@ $< # # Other rules # prep: @mkdir -p $(DBGDIR) $(RELDIR) remake: clean all clean: rm -f $(RELEXE) $(RELOBJS) $(DBGEXE) $(DBGOBJS)