It seems to me that all ready to build Edges are contained in a std::set<Edge*> (Plan::ready_). That is, they are sorted by the pointer value comparison. In mostly cases, the order comes out in line with the order build commands are read and parsed from ninja files. And this is ok for us as we generate projects in order of their dependency orders.

However, sometimes, it may happen that a cpp file from a lower level project is not schedules to compile until much later into the build process, and therefore blocking up all the linking actions, making the total build time unnecessarily long. This typically happens with a clean build, when at the start of ninja, thousands of cpp files are ready to be compiled.

I propose we add some explicit control of the build order for ready targets. Let's say every Edge object should have a member of buildorder, then Plan::ready_ can be changed to set with a compare function, which compare the buildoder member of edges.

There are a few options to determine the build order value for the edges. By default, ninja can assign a sequential number for every Edge object created. We may also introduce a build_order variable to build commands, therefore giveing the generator full control of the order.

A further benefit when above is acomplished, we can indroduce a ninja option that generates randomised build order for all edges. This would be useful to find subtle dependency problems in generated ninja files.