Re: per-target vpath alternatives

[Philip Guenther]

On 9/9/07, Bryan Ischo <address@hidden> 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