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