Make Depend -- Oops!
John Mills
johnmills at speakeasy.net
Sat Nov 27 13:39:15 PST 2004
On Sat, 27 Nov 2004, John Mills wrote:
> Freebies -
>
> On Sat, 27 Nov 2004, Conrad J. Sabatier wrote:
>
> > On Sat, 27 Nov 2004 09:43:17 +0100, Gert Cuykens
> > <gert.cuykens at 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
Sorry - I meant "minimum" --^^^^^^^
> 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 at alum.mit.edu
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>
--
- John Mills
john.m.mills at alum.mit.edu
More information about the freebsd-questions
mailing list