🚀 go-pugleaf

>In article <525@jim.odr.oz> brw@jim.odr.oz (Brian Wallis) writes:
>>[sample simple makefile] 
>>| 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'

Good so far;

>>from ./dir1/file1.c.

oops.

In article <284@sagpd1.UUCP> banderso@sagpd1.UUCP (Bruce Anderson) writes:
>[make] 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.

This is right, but a bit misleading.  Here is another makefile:

	foo: foo.o
		ld -o $@ foo.o

	foo.o: dir/foo.c
		${CC} -c ${CFLAGS} $*.c

This one has as an explicit line the same rule that appears in the
default .c.o.  The point is that $*.c (or $<, which works only in
generic rules, so I actually modified the rule a bit) expands to
`foo.c', not `dir/foo.c'.  The names of the files upon which foo.o
depends are irrelevant; they have nothing to do with the expansion
of the various macros.

Solutions to the original problem?  Unless you have VPATH, there
are no nice ones.  Make does not deal well with directories.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris