help-make
[Top][All Lists]
Advanced

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

Re: Crossing directories for target and source


From: David Boyce
Subject: Re: Crossing directories for target and source
Date: Thu, 7 Oct 2010 16:44:10 -0400

On Thu, Oct 7, 2010 at 2:29 PM, Erik Rull <address@hidden> wrote:
> I'm planning to restructure my projects source tree.
> Is it possible to write a rule that does the following:
>
> src/*.c compiles all files to build/*.o
> AND is capable to find out that one of the *.c ind the src/ has been
> modified. My plan is to run the makefile in the parent directory of both src
> and build.
>
> I'm asking that before starting restructuring because I've heard that make
> seems to have some difficulties crossing directories.

Philip has already addressed this but I'll expand on it: make itself
doesn't "cross directories" at all, nor does (vpath aside) the concept
of "current directory" mean much to it. Make looks at a set of files,
which all have absolute pathnames, and builds a graph relating their
date stamps. Then it walks that graph and forks '/bin/sh -ec "your
text here"' as required according to its rules. If there's any
dependence on the current working directory, that would be in the
"your text here" section which make doesn't know or care about.

There are a few caveats such as vpath and builtin rules, as Philip
noted. Also special variables like $@ echo back files in the way you
specified them; i.e. if you say

foo.o: foo.c

then $@ will be "foo.c", but if you specify full paths then make will
happily follow your lead. I like to use full paths everywhere, using a
BASE_DIR variable which can be inherited from an env var or derived
from $(MAKEFILES), but that's just me.

The other question of course is why you've settled on this design
already. Conventional make wisdom has no problem with operating on
remote files but it generally prefers running make in the "to", aka
object-file, directory. You certainly don't have to do it that way but
if you're going to rework the build model anyway you might want to
think about the points made in
http://make.paulandlesley.org/rules.html.

Last, if you haven't considered the relative merits of recursive and
non-recursive build models, this would be a good time to do so.  Your
original message doesn't say which you have or which you want to have.

David Boyce



reply via email to

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