raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (08/18/89)
craigb@hp-sdd.hp.com (Craig Bosworth) 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. -- -- Eric A. Raymond (raymond@ptolemy.arc.nasa.gov) G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James
desnoyer@apple.com (Peter Desnoyers) (08/19/89)
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