Re: per-target vpath alternatives

[Bryan Ischo]

Philip Guenther wrote:
> 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?
>   

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