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? Heck, you might not even need -I options. In my experience, C compilers in UNIX search the directory of the source file, whether or not that directory is named in a -I option. If so, you don't need to do anything special to get the behavior you desire: $ cat >/tmp/foo.c #include "foo.h" $ touch /tmp/foo.h $ gcc -M /tmp/foo.c foo.o: /tmp/foo.c /tmp/foo.h > I would > prefer to allow header files from otherwise separate directories to have > the same filenames if necessary, and use a target-specific vpath (or some > other alternative make construct) to allow make to use the right one for > the right target. Repeat after me: make does not use header files. Compilers use header files. > I am using gcc's -M option to generate makefile dependency rules for > 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 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.) > And if I could set the vpath uniquely for each target, > then this would work just fine. But I can't. So maybe there is an > alternate way that this thing is normally done that gets around this > issue? Or perhaps people just accept that header files in different > directories must always have unique names? 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?" The solutions are either to make the names unique, to refer to them using full or partial paths that disambiguate, or to do one of those on an as-needed basis, which just makes in more confusing and complicated then if a consistent solution had been used from the start. Philip Guenther _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
