[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
auto-dep cannot possibly work?
From: |
Mark Galeck |
Subject: |
auto-dep cannot possibly work? |
Date: |
Sat, 14 Nov 2009 10:19:37 -0800 (PST) |
Hello, as you may know, I have been working on the auto-dependency generation
for large build system using GNU make, along the lines of the relevant section
of the GNU make manual, as well as the excellent survey article
http://make.paulandlesley.org/autodep.html.
Well, I have finished but suddenly I see one big problem. With this problem, I
can't see how to make the whole thing work, without a new feature from
compilers, a feature that I don't think is implemented.
Here's the problem. Suppose I have auto-dependencies generated, as files of
the form:
foobar.o: ../include/foobar.h /include/foo.h
If you have full-paths to your include files, as shown above, then what if a
creative developer, decides to put in another header file on which foobar.c
depends, with the same name name as one of the existing ones, but in a
directory that is earlier in the compiler search path (as specified by such
things as -I options in the makefile), and does not remove the existing header
file in the later directory. (I know it may not be good software engineering,
but it is allowed and so I should be able to handle it.) Well, the above
auto-dependency makefiles will never detect that file, will think that nothing
changed, and will not rebuild foobar.o, and the system fails.
OK, I know what you may say to that. Strip the full-path information and just
have
foobar.o: foobar.h foo.h
and let
vpath %.h ...
search for those files.
This approach has a different problem. Suppose a developer puts in foobar.c a
partial path name include, like this:
#include "include/foobar.h"
Now make using vpath will search for one thing, and the compiler will search
for quite another, and this is failure - I hope you realize that by creative
arrangement of include directories including each other, and multiple files
with the same names, you can never make the two always agree no matter how you
arrange your vpath.
OK, so what seems to be the solution, is for the compiler to not emit a full
path information on include files, on -M (or -H or whatever) option, and not
the file names only, but actually, to emit the include files, _exactly_ the way
they are written in the source files, with whatever partial path there is.
I don't think existing compilers do that. Do you?
Mark
- auto-dep cannot possibly work?,
Mark Galeck <=