Date: Sat, 27 Nov 2004 15:44:52 -0500 (EST) From: John Mills <johnmills@speakeasy.net> To: FreeBSD-questions <freebsd-questions@freebsd.org> Cc: Gert Cuykens <gert.cuykens@gmail.com> Subject: Re: Make Depend Message-ID: <Pine.LNX.4.44.0411271505010.4062-100000@otter.localdomain> In-Reply-To: <20041127133242.52ca4bd1@dolphin.local.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Freebies - On Sat, 27 Nov 2004, Conrad J. Sabatier wrote: > On Sat, 27 Nov 2004 09:43:17 +0100, Gert Cuykens > <gert.cuykens@gmail.com> wrote: > > > "A Makefile rule that typically scans all C/C++ source files in a > > directory, and generates rules that indicate that an object file > > depends on certain header files, and must be recompiled if they are > > recompiled." > > > > i dont understand this. how can a object depend on something that is > > not compiled yet? Would the freebsd world not be a happier place if > > make did the dependancy thingies what ever they are automatically ? ... > Re: dependencies, it should be simple to understand if you give it a > moment's thought. Let's say you have a file "main.c" that calls > functions in "foo.c". In order for main.c to compile and link properly > to create a complete, executable program, it's absolutely essential that > foo.c be compiled and linked in as well. > What Makefile dependencies are about is ensuring that, if a change is > made to foo.c, it will be recompiled and relinked with main.c to > guarantee that the final executable is up to date in all respects. Certainly a sensible point, but not the way I understood 'makedepend' to work. As Conrad said, 'make' can be directed to compare the currency of the files upon which a particular product file (compiled object, library, executable, or other type) depends, so that all product files for which the components have changed _are_ rebuilt, but a maximum number of product files (i.e., unchanged objects being linked into a library) are unnecessarily rebuilt. Many of these rules I put in manually. 'make' only knows some 'generic' rules (what is done to change a *.c into a *.o, for example), plus the explicit dependencies I have written into my Makefile. 'makedepend' is a way to automatically generate the file-specific rules that can be deduced from a [source] file's own contents: usually those secondary files that are brought into it by '#include' pragmas. These auxiliary rules are written onto the Makefile and become part of it. These files are not necessarily separately compiled; I find your definition a bit misleading on this. 'makedepend' is given a list of files to scan, and places to look for included files. My 'depend' rule looks like this: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ depend: makedepend -- $(CFLAGS) -- $(SRCS) -- $(INCLUDES) # DO NOT DELETE THIS LINE -- make depend depends on it. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ That funky last line really tells 'makedepend' where it should write the new rules onto my Makefile. Before using a Makefile on a group of sources, or when source files are added to the build, I remove all the generate rules which have been added below the '# DO NOT DELETE ...' line and rebuild the 'depend' target - which is the Makefile itself: $ make depend Typical rules automagically added by 'makedepend' are: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ... BufRing.o: ../Llcommon/SEBase.h StdAfx.h BufRing.h Camera.o: ../Llcommon/SEBase.h StdAfx.h ../Llcommon/commonStruct.h Camera.o: ../Llcommon/secureeye.h ../Llcommon/memCtrl.h Camera.o: ../Llcommon/retCodes.h ../Llcommon/LiveShare.h Camera.h Camera.o: ../Llcommon/Common.h Pump.h BufRing.h CamData.h Snap.h INet.h Camera.o: Player.h INet.o: ../Llcommon/SEBase.h StdAfx.h /usr/include/stdlib.h ... +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The effect of these added rules is that if I change [say] 'BufRing.h' then do 'make all', 'BufRing.c' and 'Camera.c' would be recompiled, but not necessarily 'INet.c' 'make' isn't very bright, but (like 'cpp') it can be _very_ handy. - John Mills john.m.mills@alum.mit.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44.0411271505010.4062-100000>