help-make
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]