[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: |
Mon, 16 Nov 2009 12:06:39 -0800 |
>So, they are going to add a new header file to this directory. Now
EVERY source file that used to include /include1/config.h, and worked fine and
expected that, will start using /include/config.h the next time it's compiled.
>If you have reasonably common situations that meet the criteria, please
do tell!
OK here we go. What happens with that example that I showed, is
"encapsulation". /include/config.h does not "interface" with foobar.c directly
- its purpose it only to interface correctly with other files in its directory,
such as /include/foobar.h.
Then /include1/config.h , interfaces with /include/foobar1.h
As long as they both interface correctly, then foobar.c, which has to interface
correctly with foobar.h and foobar1.h, will work too.
The purpose of copying.h is so that a better implementation of the interface to
the other header files, can be done in /include1.
In fact, with this setup, foobar.c will include _both_ foobar.h files, not one.
And indeed, when I look at these things, they have modified multiple-include
guards, like
#if !defined _include_config_h_
#define...
Of course, this means to avoid conflicts, one has to extensively change the new
foobar.h. But those changes only affect what happens with the interface to the
other files in that directory.
Anyway, this is what I see done here, and, while personally I would not have 2
source files with the same name, I see it done. In fact, my boss just came by,
I explained the situation to him. Everybody here, up to the highest
management, is C-proficient. I said, here's an interview question you can use
"you have an application, you are not allowed to touch existing source files,
or existing included files, or existing build commands, how can you get the
application out of date where it has to be rebuilt?". He was very pleased with
the question and answer, and he said "definitely fix this, this is not an
uncommon situation".
> If developers are adding new
headers then surely they KNOW ALREADY the answers to these questions.
I agree with you, OK, they already know, right. So don't worry, they know what
they are doing. So then I would just have to tell them, this would be a
problem case, do rebuild it in that case. It's just, well, they forget, and if
I take care of this, they won't have to remember.
>If the user deletes include/foobar.h, then you definitely DO want the
objects that depend on that file to be recompiled. But, because your
$(wildcard ...) omitted it, make doesn't know that there's a dependency
relationship there and it won't recompile the files.
Hmm, perhaps I did not explain myself carefully enough. The dependencies are
generated, following the scheme from the GNU manual and other sources, when the
.o file is built, to be used next time the question comes up whether the .o
needs to be rebuilt.
If between those two times the user deletes (or renames) a header file
include/foobar.h, make still thinks include/foobar.h is a target, because it
still has the "basic" dependency line
foobar.o: include/foobar.h
However, the "auxilliary dependency" line
include/foobar.h: $(wildcard include1/foobar.h ...)
whether the wildcard function returns an empty list or not, in either case,
this line ensures that make will not complain that there is no way to rebuild
the target include/foobar.h.
And then, when foobar.o is rebuilt, include/foobar.h vanishes completely from
the makefile, and possibly, some new header files from the former wildcard
list, may now appear in the basic lines (and in turn, depending on them, there
may be more "potential" header files appearing on the "auxiliary lines"). And
so forth.
>The traditional way of managing deleted files is much better: it will
force a recompilation if the file disappears.
Yes the traditional way, is actually close to what I did above. The
traditional way, as explained in the well-known article, that I think you or
others here, recommended to me: http://make.paulandlesley.org/autodep.html
It is as I do above, except without the wildcard list of potential files - with
empty prerequisites list. My method adds the fix the "bizarre" problem, as
well as preserves the original method of dealing with deleted files. I checked
it works, but of course, maybe I missed some another "weird" case where it does
not work... Please tell me
Mark
- is it possible to have a prerequisite, which, when non-existent, causes make to ignore it?, (continued)
- 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), 2009/11/15
- 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) <=
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/17
- Re: auto-dep cannot possibly work?, Mike Shal, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16
- Re: auto-dep cannot possibly work?, Mike Shal, 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?, Mike Shal, 2009/11/16
RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15