views:

159

answers:

4

Assuming we have the rule:

a: b c d e

and b, c, d and e are independent of each other.

Is the order of making b, c, d, e defined? It seems that generally they will be made in order b, c, d, e, but may it sometimes happen, that the order will be different?

+1  A: 

Sure, if I use make -j a, they might all get built at the same time (depending on whether b, c, d, or e in turn have other/interrelated dependencies).

Carl Norum
This doesn't really answer the question so I'm surprised it was accepted.
Kinopiko
The question I read there is "It seems that generally they will be made in order `b`, `c`, `d`, `e`, but may it sometimes happen, that the order will be different?". I'm pretty sure I provided a counterexample. Your opinion may vary, I suppose.
Carl Norum
+1  A: 

In the right order, based on the rules you provide. For your particular example, that could mean any one of a number of different (4! = 24, from memory) orders.

All make programs are free to choose the order they like as long as the dependencies are honored. If there were other rules in your example, say c: b, then c would be made before b (but that isn't the case, as you point out).

If you need to rely on a specific order, you'll need more rules to enforce it. Otherwise make can do what it pleases. The documentation for GNU Make only states how rules are processed, not the order in which dependencies within a rule are processed. The most logical order (to me, anyway) would be the order in which they're listed but that's not guaranteed.

paxdiablo
+2  A: 

No, the order is not defined. That is the whole point in using declarative dependency-oriented programming: that the computer can pick the optimal evaluation order, or in fact, evaluate them even at the same time.

Jörg W Mittag
A: 

You can't count on the ordering.

  • make needs to do a topological sort, because the dependencies make have additional relationships. The sort that make does is potentially quite complex, as nodes in the graph may be related multiple times at different levels
  • in general sorting algorithms are not naturally stable, even for simple key-based sorts
DigitalRoss