[Top][All Lists]

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

[bug #15176] .SECONDARY changes build order

From: Paul D. Smith
Subject: [bug #15176] .SECONDARY changes build order
Date: Sun, 14 Jun 2009 06:50:34 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2009060309 Ubuntu/8.04 (hardy) Firefox/3.0.11

Update of bug #15176 (project make):

                  Status:                    None => Not A Bug              
             Open/Closed:                    Open => Closed                 


Follow-up Comment #2:

This is indeed not a bug, but not because of the reason given in comment #1. 
All POSIX-compliant implementations of make, including GNU make, _do_ provide
an implicit build order which is guaranteed to start with the first
prerequisite in the prereq list and build each one in turn until all are up to
date.  Adding parallel builds into the mix doesn't change this, but what it
DOES do is make the order of builds unreliable because some prerequisites
might take longer than others; this means you could be building things in an
unexpected order.

However, since this makefile doesn't use parallelism anyway, that's not an
issue here.

The difference here is, as noted in the description, the .SECONDARY.  The
behavior of .SECONDARY, as described in the manual, is that it marks the
target as having one aspect of a true intermediate file's behavior; this

If an ordinary file B does not exist, and `make' considers a target that
depends on B, it invariably creates B and then updates the target from B.  But
if B is an intermediate file, then `make' can leave well enough alone.  It
won't bother updating B, or the ultimate target, unless some prerequisite of B
is newer than that target or there is some other reason to update that

So here's the thing: in your example, prereq1 is secondary which means that
if it doesn't need to be run to build its parent (all), then it won't be run. 
So when make looks at prereq1 the first time it says "well, all doesn't need
to be rebuilt, so I won't run the rule for prereq1".  Then it goes to prereq2
and sees that it DOES need to be rebuilt... so it rebuilds prereq2.  Then make
discovers that "all" does need to be rebuilt afterall (because prereq2 was
rebuilt); now before it can rebuild all it DOES need to make sure that prereq1
exists so it goes back to build prereq1.

And that's why the order is different here.

You might say that as soon as make finds a prerequisite that must be rebuilt,
it should stop right there BEFORE rebuilding it and rebuild all the
secondary/intermediate files that it skipped.  Perhaps, but this still doesn't
get you identical behavior.  In this simple example it does but if prereq2
itself had lots of prerequisites then we can't know if prereq2 needs to be
rebuilt until we rebuild all those prerequisites, so those, at least, would
_still_ be built out of what we would consider "normal" order, if .SECONDARY
weren't used.

This behavior is just a side-effect of using .SECONDARY.  If you have real
build oder requirements you need to declare them explicitly in the makefile.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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