Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!sun-barr!apple!apple.com!desnoyer From: desnoyer@apple.com (Peter Desnoyers) Newsgroups: comp.lang.c Subject: Re: No make dependencies on binaries allowed (was Recommend a C compiler?) Message-ID: <3699@internal.Apple.COM> Date: 18 Aug 89 21:32:50 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 31 References:<660054@hpclwjm.HP.COM> <3642@ohstpy.mps.ohio-state.edu> <2420@hp-sdd.hp.com> <2009@ptolemy.arc.nasa.gov> In article <2009@ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) writes: > >A project file might contain (from Turbo C User's Guide, p. 36): > > > MYMAIN (MYFUNCS.H, SPECIAL.OBJ) > > MYFUNCS (MYFUNCS.H, OTHER.LIB) > > SPECIAL.OBJ > > OTHER.LIB > > Of course, there is no way a LIB or OBJ file could have a compile-time > effect on a source file. Not necessarily true . I've written a make file (with lots of awk code to go with it) to compensate for a broken cross-linker where the dependencies run sort of like: .c -> .asm -> .obj -> .map -> .asm -> .obj -> .map -> .cmd -> .hex (where .cmd is a linker command file) Also, what about assembler equate generators - e.g. grep "#define" foo.h | awk -f gnarly.awk > equgen.c cc equgen.c -o equgen equgen > foo.equ In this case the object is only an intermediate step, but you certainly could write the makefile in such a way that source (foo.asm) would depend on object or binary (equgen.o & equgen). Peter Desnoyers Apple ATG (408) 974-4469