[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: auto-dep cannot possibly work?
From: |
Mark Galeck (CW) |
Subject: |
RE: auto-dep cannot possibly work? |
Date: |
Sun, 15 Nov 2009 17:19:50 -0800 |
>So the "solution" I settled on, is, I checked, that currently in our system no
>file depends on two include files with the same name. Then I will not use
>full-path include dependencies, but only file names:
foobar.o: foobar.h foo.h
Then vpath is split off into a separate makefile, included in the main one.
And the developers are reminded, that it is their responsibility, if they make
a new directory, to update -INCLUDE options as needed, and the file with vpath
directives, one of them being
vpath %.h
-------------------
Well no, of course I was wrong, there are in fact lots of cases where one
source depends on multiple includes with the same names. So that "solution" is
not.
But, here is a good try, I think. Earlier today I asked a silly question
about ignoring a nonexistent target completely. Well, it's easy (see below).
So, the full solution to the dependency problem, would be,
if a source foobar.c has #include "../include/foobar.h", then do not just do
something like:
foobar.o: ../include/foobar.h
but add the following. When you generate your dependencies (at the previous
build), collect all the include files, and have a Perl script that generates
header files full paths, with same names as existing include files, that could
potentially land in the compiler search path.
If one such file is: ../include1/foobar.h
then add this:
ifneq (,$(wildcard ../include1/foobar.h))
../include/foobar.h: ../include1/foobar.h
else
../include/foobar.h:
endif
----------------------
Great, right? Next time we run make, it finds out if such offending new header
file, with the same name as an old one, and potentially in the search path,
exists, if so, we depend everything on it, that already depended on the old
header file. And then after we remake foobar.o, include1/foobar.h may or may
not be in the dependency list (depending on whether it was actually in the
search path for the compiler). If the file does not exist, nothing happens.
OK, there is one problem! What if a particularly clever developer, decides to
not "copy" or make a new file with the same name as the old one "foobar.h".
But instead, if he does
>mv include1/foo.h include1/foobar.h
Now we are still in trouble. Because the timestamp for foobar.h, created this
way, would be as old as foo.h. And so yes make will notice that the new
foobar.h is there, but will think it is an old file, older than
include/foobar.h, and now again foobar.o will not be rebuilt.
Anybody knows what to do about this??
- auto-dep cannot possibly work?, Mark Galeck, 2009/11/14
- Re: auto-dep cannot possibly work?, Paul Smith, 2009/11/14
- is it possible to have a prerequisite, which, when non-existent, causes make to ignore it?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?,
Mark Galeck (CW) <=
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- Re: auto-dep cannot possibly work?, Stephan Beal, 2009/11/15
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/15
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16