Path: utzoo!attcan!uunet!wyse!vsi1!ames!ucsd!ucsdhub!hp-sdd!ncr-sd!sagpd1!banderso
From: banderso@sagpd1.UUCP (Bruce Anderson)
Newsgroups: comp.bugs.misc
Subject: Re: bug in make
Keywords: make subdirectories BUG
Message-ID: <284@sagpd1.UUCP>
Date: 31 Jul 88 08:26:43 GMT
References: <525@jim.odr.oz>
Reply-To: banderso@sagpd1.UUCP (Bruce Anderson)
Organization: Scientific Atlanta, Government Products Div, San Diego, CA
Lines: 54

In article <525@jim.odr.oz> brw@jim.odr.oz (Brian Wallis) writes:
>
>Is this a bug in make, or am I just missing something obvious?
>The simple example for the make file is as follows...
>
>| 
>| exe: file1.o
>| 	ld -o exe file1.o
>| 
>| file1.o: dir1/file1.c
>| 
>
>'Makefile' is in '.' and the file 'file1.c' is in './dir1'
>
>I want to make the file 'exe' from 'file1.o' in '.' where 'file1.o'
>depends on './dir1/file1.c' as is stated in the Makefile. I expect
>the default '.c.o:' rule to be used to generate the file 'file1.o'
>from ./dir1/file1.c.
>
>I can get this to work by including an explicit rule for the
>'file1.o' dependency, but this is a little awkward since I use mkdep
>to generate the dependancies and have a large number of source files in
>a large number of subdirectories.
> [lots of debug output deleted]
>--
>Brian Wallis (brw@jim.odr.oz)		    O'Dowd Research P/L.
>	(03) 562-0100 Fax: (03) 562-0616,
>	Telex: Jacobs Radio (Bayswater) 152093


I had the same problem on our HP-9000 system running HP's version of Unix,
HP-UX and simply ended up using explicit rules because I couldn't figure out
any other way to do it. Then I ran across a PD version of make and looked
at the source (which I assume is similar in intent to the Unix version)
and discovered an explanation for the behaviour experienced.
Basically, when you have a dependency in the Makefile such as:

test.o: test.c

and don't give an explicit rule, it goes out and check the modifcation
times of the two files and then determining that is needs to update
test.o it goes out to itts implicit rule base
and looks for a way to generate test.o. It however, *TOTALLY IGNORES*
the test.c filename on the dependency line and generates the source
file name from the target file name. So for example, if you have a line

test.o: whatever.c

it will try to make test.o from test.c NOT whatever.c even though whatever.c
is in the same directory. So you can see that in the case of a subdirectory,
it will go out and check the dependency of the source file in the 
subdirectory but then generate an entirely new name which by default is
in the current directory to try to make the target out of.
As far as I can tell, this is the way that the Unix make works as well.