From owner-freebsd-questions@FreeBSD.ORG Fri Mar 18 16:38:55 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6B7F16A4CE for ; Fri, 18 Mar 2005 16:38:55 +0000 (GMT) Received: from april.chuckr.org (april.chuckr.org [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46BCB43D4C for ; Fri, 18 Mar 2005 16:38:55 +0000 (GMT) (envelope-from chuckr@chuckr.org) Received: from [66.92.151.195] (july.chuckr.org [66.92.151.195]) by april.chuckr.org (Postfix) with ESMTP id 50D4A11958; Fri, 18 Mar 2005 11:39:36 -0500 (EST) Message-ID: <423B03F7.70405@chuckr.org> Date: Fri, 18 Mar 2005 16:38:15 +0000 From: Chuck Robey User-Agent: Mozilla Thunderbird 1.0 (X11/20050316) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathon McKitrick References: <20050318031137.GA99419@dogma.freebsd-uk.eu.org> In-Reply-To: <20050318031137.GA99419@dogma.freebsd-uk.eu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-questions@freebsd.org Subject: Re: How to include header files in makefiles X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 16:38:56 -0000 Jonathon McKitrick wrote: > Hi all, > > I'm setting up a build system for a small project and I want to use included > makefiles. I have a base.mk that looks like this: I will answer here, but be aware that you're getting all of my prejudices too, so take things with a grain of salt. First item deals with the .path statements, and more specifically, your use of relative addressing. It's my own experience that, if you use relative addressing, you make troubleshooting a broken build much more difficult, because 1) relative addressing means you have to be forever translating paths in listings, and very often the number of include paths gets to be rather long. 2) all the stuff like "../.." in listings is quite difficult to read 3) with the $(.CURDIR) variable, it's extremely easy to use absolute addressing. You can also make use of $(.OBJDIR), and it's not so hard to make makefiles that work off of read-only sources like cdroms. > > .PATH.h : ../ ../include > .INCLUDES : .h > > CFLAGS = -O -pipe -Wall -g > CFLAGS += $(.INCLUDES) > > OBJS = ${SRCS:R:S/$/.o/g} > > and a bin.mk that looks like this: > > include ../include/mk/base.mk > > all: ${BIN} > > ${BIN}: ${OBJS} > ${CC} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC} > > so that a makefile for a specific program looks like this: > > BIN = app > SRCS = app.c > LDFLAGS += -pthread > include ../include/mk/bin.mk The Make(1) man page doesn't show "include", the advertised command is ".include". If you use .include, then you can modify your make, if you want, with the -m argument, and so get specific directories to be added to the search path for make include files. I'm not sure, but I think that raw "include) is more a gmake item, and it's absolute addressing. Don't forget the "-" argument, so that you allow includes to fail if they need to, like for generating dependencies. > > But I'm having a problem figuring out how to handle header files. I have > some that are local to this binary, but others are in the project include > directory. > > How can I include the .h files so the .c files are recompiled when the > header files they require are changed? GNU make has 'make depend' but I'd > like a better, BSDmake-centric way, if possible. Well, did you look at the files in /usr/share/mk, and specifically bsd.dep.mk? You can even use the FreeBSD sources to figure out (to use as examples) how things should work. Don't forget the use of -m, because you can use it to add to the include directory list, and so be able to add your own include files without corrupting the system files. I honestly keep on switching back and forth, between thinking that the best make is bmake, or gmake. They both have key items that make them uniquely better. > > Thanks for your help, > > jm