Philip Guenther wrote:
On 9/9/07, Bryan Ischo <[EMAIL PROTECTED]> wrote:
...
If I have separate sub-directories in which source and header files are
located, and I want targets built from sources in one directory to have
dependencies on header files from that subdirectory, and targets built
from sources in another directory to have dependencies on header files
from *that* directory, then without separate vpaths, I have to ensure that
the header file names are unique between the two directories.
Umm, why would you need a vpath to find header files? The compiler
will look for include files based on the paths passed to it via -I
options and any techniques for autogeneration of dependencies MUST
both pass those through to the compiler *and* put actual paths (and
not just names) in the generated dependency output. That covers the
use of the .h files as dependencies of the objects; what are you doing
that requires make to know more than that?
My apologies for not being clear in my previous email. I will answer
this issue below.
making my source code files dependent on the header files they include,
and the rules it generates are just file names and thus must rely on vpath
to locate them.
I am using gcc's -M option to generate makefile dependency rules for
I have no clear idea what you mean when you say "the rules it
generates are just file names". It ain't a rule if it doesn't include
a bare colon, so there's no way a rule could be "just file names". If
you mean that either the target or one or more of the dependencies of
the generated rules do not include full paths, well, please say so and
be precise about which parts are "just file names" and which aren't.
Giving an example would probably help.
(Yes, my example of gcc -M above has "just a file name" for the
target, but the header file path is *not* just a file name, so vpath
searching doesn't apply to it.)
Sorry, I wasn't very clear and I didn't mean to say "the rules it
generates are just file names". I meant to say "the rules it generates
are just dependencies on file names". What gcc -M does is search source
files for header file dependencies, and then emit files with make rules
that look like this:
foo.o: foo.c foo.h
Then you -include this makefile fragment in your makefile and you get
automatically maintained dependencies that cause object files to be
rebuilt whenever the header files that the source file #includes are
modified.
The basic problem I am trying to deal with is, given a bunch of rules
like this generated by gcc, how do I tell make how to find the files
whose name the compiler has written into the rule, such that when make
examines the rule, it is able to properly locate these files?
I could just build up a vpath as I process my "Makefrag" files, but
since vpath is global in its effect, it means that every one of the
gcc-generated dependency rules will search the same paths for files, and
this may "mask" later files if there are earlier files with the same name.
I would prefer a way to have each rule for building a target, had its
own vpath, so that I could control the search with fine granularity.
It's generally a good idea for them to be unique for the simple reason
that if they aren't, then mixing the modules in a single program
becomes more difficult and confusing to the programmers. "Bob wrote
foo.h, but which did he mean? Am I sure the build system is getting
the right one? I now need the other foo.h in this module; how can I
get it without breaking the existing reference to the former?"
I can certainly agree with this; and the more I think about this
problem, the more I realize that perhaps there are some fundamental
errors in my assumptions about how this needs to work.
I'm mostly worried about source files for test programs and their header
files; whereas I would normally naturally have unique names for all
header files that are part of the public API that I am development, for
test programs in separate directories, I may want to re-use header file
names like "test.h" and have each dependency rule generated by gcc "just
work" for the individual test programs in different subdirectories which
happen to use the same header file name "test.h".
I'll have to think about this some more. But your response was helpful
in making me realize some points that I hadn't before.
Thank you,
Bryan
_______________________________________________
Help-make mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-make
