On Thu, Dec 24, 2009 at 7:16 AM, Paul Smith <psm...@gnu.org> wrote:
> On Thu, 2009-12-24 at 01:08 -0800, tom honermann wrote:
>> There are many valid orders in which the targets can be built. When make
>> is invoked with the parallel execution (-j) option, the order in which the
>> non-dependent targets are scheduled has a significant impact on the total
>> run time.
>
> You can already completely control the order in which targets are
> invoked, even when using -j.
>
> At all times, make will try to build prerequisites starting with the
> first one in the prerequisite list, and continuing in order to the last
> one in the list.
The problem is that only works for the direct dependencies. I think
the OP's request is more about stuff buried more than one level deep.
E.g., program "prog" requires two libraries, each one of which has
multiple objects of varying size, with one object in each taking
particularly long to compile, say:
prog: prog.o liba.a libb.a
liba.a: a1big.o a2.o a3.o a4.o a5.o
${AR} rc $@ $^
libb.a: b1big.o b2.o b3.o b5.o b5.o
${AR} rc $@ $^
Now, let's say a2.o, a3.o, a4.o, a5.o and b1big.o are out of date.
"make -j2 prog" will rebuild them in that exact order, but it would
take less total time if make started rebuilding b1big.o first. Static
reorderings of the prerequisite lists can't solve this.
Personally, while I'm sympathetic to the concern, I think this is the
sort of problem where the consequences of the solution are likely to
be greater than expected and it should probably be handed to some CS
grad student as a possible research project. Isn't that what grad
schools are for, banging on possibly open-ended problems?
Philip Guenther
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
