schorr@WHEATIES.AI.MIT.EDU (Andrew Schorr) (10/19/88)
Roland,
I am having a problem with recursive makes.
I am running version 3.13 of GNU Make.
Directory /x/y contains Makefile and file1.c
Contents of Makefile:
prog: file1.o ../z/file2.o
$(CC) $(LDFLAGS) -o prog file1.o ../z/file2.o
../z/file2.o: FRC
cd $(@D); $(MAKE) $(@F)
FRC:
Directory /x/z contains Makefile and file2.c and file2.h
Contents of Makefile:
file2.o: file2.c file2.h
When I am in directory /x/y and I type make prog, I would like
make always to invoke the recursive make in directory /x/z.
The top-level make should decide whether to relink based on
whether the sub-make was forced to recompile. Using this scheme, I
need to specify the dependencies of file2.o only in the Makefile in
directory /x/z.
Suppose prog postdates file1.o and file2.o, but file2.h postdates file2.o.
In directory /x/y, I type make prog. Nothing happens.
You can see that this is not the desired behavior.
Note that if I type make -n prog, I get the following response:
cd ../z/; make file2.o
cc -c file2.c -o file2.o
cc -o prog file1.o ../z/file2.o
This is correct. Furthermore, it appears to be inconsistent with
the behavior obtained without the -n flag.
Note that Sunpro 3.5 (and, presumably, SunOs 4.0) Make handles this correctly.
Another curious fact: suppose that file2.h does not postdate file2.o
and that everything is in fact up to date.
If I type make prog, nothing happens.
Sunpro Make gives the expected behavior:
cd ../z; make file2.o
`file2.o' is up to date.
`prog' is up to date.
If I type make -n prog, I see
cd ../z/; make file2.o
cc -o prog file1.o ../z/file2.o
Again, this behavior seems inconsistent.
I am also surprised by the line indicating that it will
be relinked. (Note, however, that Sunpro 3.5 make with the -n flag
gives the same result in this case.)
Clearly, my FRC target does not achieve the desired effect under GNU Make
(although this technique does work with Sunpro Make). It is not clear to
me from the documentation whether this should work or not. In any case,
there does seem to be an inconsistency between the results with and
without the -n flag.
Thanks for your help,
Andrew Schorr <beareq!schorr@wheaties.ai.mit.edu>