Re: Fetching sources for multiple interdependent targets

[Vesselin Peev]

Hello Paul,

Thank you for responding! Please read and tell me if I am doing something
wrong, or odd.

> "Paul D. Smith <address@hidden> writes:
> >"Vesselin Peev" <address@hidden> writes:
>  vp> I have multiple interdependent targets in a single GNU Makefile,
>  vp> each depending on source files that have the same names as the
>  vp> source files in another target but residing in a different
>  vp> directory. How do I fetch the files with the same names from the
>  vp> appropriate directory for each target unless I specify the full
>  vp> path for each file?
>
> I don't really understand what you're trying to do (a small, simple
> example would be helpful), but I think the short answer is "you can't".

Tell me if I am wrong, but I think "interdependent" has been the reason for 
your
confusion. The inter- prefix should not be there, and I should have made it
clearer that targets depend on other targets, in fact, I could have omitted
(inter-)dependent entirely.

My makefile uses variables and substitution but here's a simplistic
illustration:

prj1: main.o second.o
prj2: main.o second.o

main.o and second.o on the first and second line need to refer to main.o
and second.o in directory ../prj1/ and a different main.o and second.o in
directory ../prj2/ respectively.
Until I didn't realize I cannot, I assumed, by logical extension,
I could write something like:

vpath prj1 ../prj1/
vpath prj2 ../prj2/

which would mean, all files for target prj1 would be taken from ../prj1/ and
all files for target prj2 from ../prj2/
Such a syntax allowing pattern-matching could potentially be supported as 
well:

vpath prj1 %.cc ../prj1/
vpath prj2 %.cc ../prj2/

It seems quite logical to me to expect this type of functionality to exist.

By dependent targets I mean
prj1: main.o second.o prj2

The whole point in mentioning dependence has been that I wanted to avoid 
someone
just telling me that I better put prj1 and prj2 in two separate Makefiles 
and
make use of the current functionality of VPATH and/or vpath. When the target 
are dependent,
I would lose strict dependency checking. That said, I do have such dependent 
targets in
my real Makefile.

So I now do not have *any* use for VPATH and vpath, and have the an 
appropriate directory prefix
before each source file. I hoped there is a better way that would save me 
from
repeatedly writing prefixes. Of course, now I have the equivalent of:

prj1: ../prj1/main.o ../prj1/second.o
prj2: ../prj2/main.o ../prj2/second.o

However, that creates a second problem -- main.o and second.o are created 
not
in the current directory, but in the ../prj1/ and ../prj2/ directories,
undesirably mixing them with the .cc source files in those directories. GNU 
Make probably
does it because otherwise files with the same names can overwrite each 
other, but
in fact this does not avoid the problem in all scenarios -- what if we have
a separate copy of Make invoked manually by the user from a different build
directory (though "make -f")? Overwriting will still be possible,
even though the .o output files are in unique directories under the
source tree. I hope I have been clear.

So I started searching for a way output files to become unique in the build
directory (the one from which make is invoked).
I found the way thanks to an old USENET post of yours (Paul D. Smith),
describing the $(OBJDIR)/%.o: $(SRCDIR)/%.c idiom. Thank God this is 
supported by GNU Make.
I used the same technique for handling .d files. Of course, one need to use 
the technique for each source
directory, but this is not a significant problem, I think.
By the way, before I look more seriously into it, is your "Advanced 
Auto-Dependency Generation" method,
http://make.paulandlesley.org/autodep.html suited to handling files with 
same names, when the need be?

> If you're dealing with files with the same names in different
> directories you generally need to write out the directory prefix, or how
> can make know which ones you meant?

Couldn't make write out the prefix for us, via my vpath extension? ;)

Again, thank you for taking the time to answer and save the post from 
falling between the cracks
(considering the delay of the response). I understand that your (Paul's) 
volunteer work requires a lot
of time and effort (I have managed a forum with deep discussions myself, and 
I know
what a time sink it can be), and sometimes it is not worth it. Just know 
that someone here is grateful
for what you have done, and you have helped him on his way.

Best regards,
Vesko

P.S. I've CC'd the letter personally to you as well, since I have noticed 
that you've CC'd it to me.