Adding a directory for the headers in a Makefile
Hello I would like to ask you, If someone knows how can I add a directory for the header files in the Makefile to avoid the error *.h not found, I have tried this option but does not work:
INC_PATH := -I /directory/to/add 2 Answers 2
At least for GNU make, try the implicit variable CFLAGS , as in:
Although the goal is ultimately to affect the value of CFLAGS (as suggested by @unwind), it is often not a good idea to simply set the value of CFLAGS as it is often built out of many pieces. You have to understand the structure of the makefile, and the set of macros used.
Eduardo asked: Can you post macros to do the same?
Yes, but whether they are helpful depends on how your makefiles are structured. Here’s a moderately complex example from one of my makefiles.
CC = gcc -g XFLAGS = -Wall -Wshadow -Wstrict-prototypes -Wmissing-prototypes \ -DDEBUG -Wredundant-decls #CC = cc -g #XFLAGS = UFLAGS = # Always overrideable on the command line DEPEND.mk = sqlcmd-depend.mk INSTALL.mk = sqlcmd-install.mk ESQLC_VERSION = `esqlcver` OFLAGS = # -DDEBUG_MALLOC -g OFLAGS = -g -DDEBUG -O4 PFLAGS = -DHAVE_CONFIG_H OFILES.o = # rfnmanip.o # malloc.o # strdup.o # memmove.o VERSION = -DESQLC_VERSION=$ #INC1 = #INC2 = INC3 = /usr/gnu/include INC4 = $/incl/esql INC5 = . #$/incl INCDIRS = -I$ -I$ -I$ -I$ -I$ LIBSQLCMD = libsqlcmd.a STRIP = #-s LIBC = #-lc_s LIBMALLOC = #-lefence LIBRDLN = -lreadline LIBCURSES = -lcurses LIBPOSIX4 = -lposix4 LIBG = #-lg LIBDIR1 = $/lib LIBDIR2 = /usr/gnu/lib LIBJL1 = $/libjl.a LIBJL2 = $/libjlss-$.a LIBTOOLS = $ $ LDFLAGS = $ $ -L$ $ $ \ $ $ $ CFLAGS = $ $ $ $ $ $
This a makefile for a program of mine called sqlcmd (a name chosen a decade and more before Microsoft created a command of the same name). I assume that the make program has a rule for compiling C code to object like:
and that the rule for linking a program from a set of object files listed in the macro OBJECTS looks like:
As you can see, there are separately settable macros for the ESQLC_VERSION (the version of Informix ESQL/C in use, derived by default by runing a script esqlcver ), then the include directories via INC1 to INC5 and INCFLAGS (there can be quite a lot of these, depending on platform), and optimizer flags (OFLAGS), extra flags (CFLAGS), user-defined flags (UFLAGS — an idiom I use in most of my makefiles; it allows the user to set UFLAGS on the make command line and add an extra flag to the build), and a bunch of library-related macros. This is what it takes for my development makefile to be tunable with minimal fuss to my development platform, which can be Linux, Solaris or MacOS X. For consumers of the program, there is a configure script generated by autoconf , so they don’t have to worry about getting those bits right. However, that has a strong genetic resemblance to this code, including the UFLAGS option.
Note that many systems for makefile building have a mechanism for setting CFLAGS faintly similar to this — and simply assigning to CFLAGS undoes the good work done by the system. But you have to understand your makefile to be able to modify it sanely.
Makefile with headers including headers
How do I write a target for app.o in a makefile? Should I include all three headers in the prerequisites?
6 Answers 6
Yes, you should list all dependencies of app.c which might need a recompilation of app.o.
You might find g++ -MM app.c useful: -MM will list all dependencies of app.c in a make format. You can even automate it and have your makefile semi-automatically handle dependencies.
app.o : app.c app.h model/world.h controller/controller.h gcc -c app.c Yes, you need to include all three headers as dependencies. Makefiles: if anything on the right of : has changed, then it needs to remake the thing on the left. If you fix a bug in your controller and cut out three arguments from one of the functions, and the app calls that function from the controller, then the app needs to be remade to deal with the change.
Otherwise when the app walks over to the controller and asks for function X with 5 arguments, the new and improved controller isn’t going to know what the hell the app is talking about. Error will be thrown. Fire and blood everywhere. And it all ends in tears.
This is an example how I solved this issue. gcc -MM generates rules from the given source file’s include directives. Try it on a source file containing include directives to see it’s output.
# src/x.c src/y.c . => build/x.o build/y.o . OBJ = $(patsubst src/%.c,build/%.o,$(wildcard src/*.c)) # src/x.c src/y.c . => build/x.d build/y.d . # `-> these files will include the generated rules INCLUDE_PREQS = $(patsubst src/%.c,build/%.d,$(wildcard src/*.c)) all: main main: $(OBJ) gcc -o $@ $^ ## compile object from src/x.c to build/x.o # src/x.c src/y.c . => build/x.o build/y.o build/%.o : src/%.c gcc -o $@ -c $ < ## generate header prerequisite rules # -MT $(patsubst build/%.d,build/%.o,$@) # `->set the generated target to be build/%.o build/%.d: src/%.c gcc -MM -MT $(patsubst build/%.d,build/%.o,$@) $ < >$@ ## include the generated rules include $(INCLUDE_PREQS) You should never need to manually specify header dependencies in makefiles.
Add -MMD -MP to compiler flags. It will make the compiler output .d files in addition to .o . Those are little makefiles specifying the dependencies. You then -include them into the main makefile.
SOURCES := 1.c 2.c program: $(patsubst %,%.o,$(SOURCES)) gcc $^ -o $@ %.c.o: %.c gcc -MMD -MP $< -c -o $@ -include $(patsubst %,%.d,$(SOURCES)) SRC = $(wildcard *.c) OBJ = $(patsubst %.c, %.o, $(SRC)) DEP = $(patsubst %.o, %.mm, $(OBJ)) include $(DEP) app: $(OBJ) $(CC) -o $@ $(OBJ) .FORCE: %.mm: .FORCE $(CC) -MM $*.c > $*.mm Here: DEP is a list of dependency files that need to be included (ending in mm). There is a rule to build the mm files that generates the dependency for the file. You force the build of the dependencies that are then included as dependencies to check your actual dependencies
No, you should not list the headers as dependencies! This is redundant with the specification that already exists in the form of your #include directives. And sooner or later redundancy usually causes problems, because as your project grows you will end up with inconsistent lists.
There is also a widespread though naive misconception that only header files are dependencies. This can lead to wrong builds, because many other reasons like changed command line switches, a changed compiler or changed hardware architecture, get overseen.
The solution to both problems is to use a reliable build tool: makepp handles these cases and can even scan for sub includes in include files that weren't even built yet, when you started it.
There is much more to makepp. Besides doing almost all that GNU make can, there are lots more useful things, and you can even extend your makefiles with some Perl programming.