john@beaudin.UUCP (John Beaudin) (08/06/90)
I have a target with a depndacy in another directory. I want the makefile to execute in the manner suggested by the following code fragment: foo.o: ../src/foo.c or perhaps foo.o: /u/src/foo.c My make terminates silently without doing anything. I find it hard to believe that make is unable to process the dependacy just because it's in a non-current directory. After all, the token '../src/foo.c' could get passed to some open() or fopen() statement in C, and the open function can certainly find this file, can't it? I find it easier to believe that I'm doing something wrong. -- My .signature is awaiting apropriate display technology
guy@auspex.auspex.com (Guy Harris) (08/07/90)
>I find it hard to believe that make is unable to process the dependacy >just because it's in a non-current directory. After all, the token >'../src/foo.c' could get passed to some open() or fopen() statement in C, >and the open function can certainly find this file, can't it? Yeah, but so what? The problem isn't that "make" can't *find* the file, it's that it doesn't know what to do with it once it's found it. It really *isn't* aware that, in order to make "foo.o", it should compile "../src/foo.c"; it knows that "foo.o" *depends* on it, but it doesn't understand what the dependency really is - the fact that its name ends with ".c" and that the rest of the name matches what comes before ".o" in the target nonwithstanding. (This isn't specific to SCO UNIX 3.2, BTW. SunOS 4.0.3's "/usr/old/make", which is derived from the S5R2 "make", gave the same behavior as SCO's S5R3.2-derived one; SunOS 4.0.3's "make", which is mostly a Sun creation, does the same thing.) Try giving it explicit rules to do that compilation, as in: foo.o: ../src/foo.c $(CC) $(CFLAGS) -c ../src/foo.c