automake
[Top][All Lists]
Advanced

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

Re: BUG: Solaris make & automake, VPATH, subdir sources and SUBDIR_OBJE


From: Henrik Nordstrom
Subject: Re: BUG: Solaris make & automake, VPATH, subdir sources and SUBDIR_OBJECTS
Date: Mon, 15 Oct 2001 17:51:58 +0200

Robert Collins wrote:

> Using the $< is fine IFF the relative path is consistent and we are
> happy with potentially random object file location... can you confirm
> that using $< puts the object files in the same relative path as the
> source files? (ie not the current directory).

$< is "the first dependency". Has nothing to do with targets/object
files. $@ is the object file.

I can confirm that the rule

.c.o:
        [...] $< -o $@

finds the correct sources in the subdirector and puts the object in it's
expected directory. Per definiton it must put the object correctly as it
is beeing called for resolving the specific object file including
directory path.

What I can accept is that there most likely is make versions out there
who cannot deduce the source path given an implicit rule and a path to a
object file outside the current directory.

> As above, this isn't a VPATH issue, it's for arbitrary source location
> and object file location.

All this test does is trying to figure out the selected source path. It
has nothing to do with object locations. The test tries to deduse the
source VPATH given the relative source path.

Object locations is a feature of how the dependencies are build, not the
Makefile shell scripting searching for the source (which Make has
already done in it's dependency tracking, or else the rule would not
even execute).

The case I see this odd test required for is supporting make versions
which does not support $< on explicit targets and at the same time
support VPATH enabled make version.

If VPATH is not to be supported then the test is not required as the
exact path is then always known explicitly in the makefiles.

If VPATH is to be supported on make version supporting it, and it is
acceptable to at least require (independent of the use of VPATH or not)
a make program that always sets $< to the path of the first dependency
then the test is not required as the full source path is always known.

I perfectly well understand that to support make programs not setting $<
on explicit rules, and at the same time support VPATH enabled make
versions then one must use a test like the one discussed. However, if
one already has the requirement that the make program used must support
$< then the need for such complicated tests vanish, and with them all
the possible complications the test is causing. Having two different
things doing the same thing in parallell and required to end up in the
same conclusion is stupid and should be avoided unless absolutely
required.
                                                                                
Regards
Henrik Nordström
Squid Hacker



reply via email to

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