[Top][All Lists]

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

Re: Question about order dependencies

From: drwowe
Subject: Re: Question about order dependencies
Date: Sun, 20 Sep 2009 12:33:30 -0700 (PDT)

Philip Guenther-2 wrote:
> On Sun, Sep 13, 2009 at 11:11 PM, drwowe <address@hidden> wrote:
>> Suppose I have the following makefile:
>> foo: ...
>>   ...
>> bar: ...
>>   ...
>> all: foo bar
>> Here's the problem:  I need to make sure foo completes before bar is
>> started, but only if foo was going to be executed anyway.  The obvious
>> thing, making a dependency "bar: foo" is wrong, because the user needs to
>> be
>> able to say "make bar" on the command line without building foo.
> Hmm, could you give an example of what the 'foo' and 'bar' targets
> would be doing?  Apparently the 'bar' target doesn't really rely on
> 'foo' even existing, so where does the requirement for 'foo' to be
> built before 'bar' come from?

Foo actually does have a logical dependency on bar.  In the real example Foo
builds an application and Bar builds a bunch of libraries.  The only thing
is, "make bar" wastes time because the library code isn't updated as often,
so "make foo" spends valuable seconds recursing into bar's subdirectories
and checking all of bar's dependencies.  These seconds add up when make foo
gets run frequently as it does when I'm debugging.  That's the purpose of
this question is to avoid the time spent checking dependencies when I
explicitly request "make foo".  Basically I want to tell make: "I already
know bar is up to date, so don't bother recursing and checking timestamps
because it's a waste of time"

Philip Guenther-2 wrote:
>> Anyway, I came up with a very ugly workaround by checking the
>> and adding "bar: foo" conditionally if "all" or "foo" is on the command
>> line, but I was wondering if there was an easier way to impose ordering
>> constraints on goals without triggering new goals?
> Depending on why there's this ordering requirement, that may actually
> be the semantically cleanest solution...

Fair enough.  As I said, it's basically a performance optimization so the
current solution is good enough, I was just wondering whether there was a
more general approach.  Makefile optimization seems to be tricky because I'm
trying to override "correct" behavior for performance purposes.
View this message in context:
Sent from the Gnu - Make - Help mailing list archive at

reply via email to

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