[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fetching sources for multiple interdependent targets

From: Vesselin Peev
Subject: Re: Fetching sources for multiple interdependent targets
Date: Fri, 26 Aug 2005 18:00:58 +0300

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

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 ../prj1/
vpath prj2 ../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, 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,

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]