Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: sco unix 3.2 make problem
Message-ID: <3832@auspex.auspex.com>
Date: 6 Aug 90 18:46:54 GMT
References: <1404@beaudin.UUCP>
Organization: Auspex Systems, Santa Clara
Lines: 22

>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