bugmake - Bugs: bug #15176, .SECONDARY changes build order


bug #15176: .SECONDARY changes build order

Submitter:  None
Submitted:  Fri 09 Dec 2005 07:06:26 PM UTC
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  None Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:
       No canned response available


Sun 14 Jun 2009 06:50:32 AM UTC, 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 aspect:

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 target.

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.

Paul D. Smith <psmith>
Project Administrator
Fri 20 Jan 2006 12:57:15 AM UTC, comment #1: 

That really is not a bug.  Targets or prerequisites in the same list have equal priority, equal precedence.  Make is free to build them in any order.  You must add more rules when you want to enforce a particular order:

prereq2 : prereq1

That requirement is especialy true when you do parallel builds!

Fri 09 Dec 2005 07:06:26 PM UTC, original submission:  

When using .SECONDARY, the build order changes. Normally, the prerequisite build order on the target line is from left to right, but when .SECONDARY is used, this order changes. Example:

all: prereq1 prereq2

        @echo 1

        @echo 2

.SECONDARY: prereq1

Run with and without .SECONDARY (comment it out), and the order changes (1-2 and 2-1).

I have seen this bug on linux using 3.80 and 3.81Beta3



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-06-14 psmith Open/ClosedOpen Closed
    2009-06-14 psmith StatusNone Not A Bug

    Back to the top

    Powered by Savane 3.9