%% [EMAIL PROTECTED] writes: g> 1. It does not remove each .exe after using it to build a .r. When a g> single .r has finished being built, I expect its intermediate .exe g> prerequisite to be removed.
>> That's not the way it works. The intermediate files are all >> removed only at the end of make's processing. Make cannot know >> whether a given target will need to be used more than once during a >> build, so it can't delete them "as it goes". If it did then it >> would have to re-build them the next time they were needed, which >> is bogus. g> Why can't it figure out the last dependent which uses an g> intermediate, and remove the intermediate target after building the g> last dependent? Is the relative order of the targets that get built g> fixed at the start of a particular make invocation, or does it g> change dynamically? If it is fixed, then can't you traverse the g> targets in the order that they will be built, and find the last one g> which depends on an intermediate? You could traverse the target g> graph once, marking all intermediate targets along the way with g> their last usage. Then if the build is ever at a point farther g> along than the last usage of an intermediate target, it can be g> removed. It does not matter if targets are skipped because they are g> already up to date, as long as the order stays the same. All that you say is true, it COULD be done that way. But, that's not the way make works. Make does NOT fully examine the entire dependency graph and make a plan of all the targets that it will need to build first, then proceed to build them all. Instead, make walks the dependency graph and, each time it finds a target that is out of date (after all the target's prerequisites have been considered), it rebuilds that target. Then it goes on to the next one, and so on. When all the prerequisites of the original target have been considered, the make is done. That's how make works; that's how all make programs I'm aware of have always worked. We sometimes get people asking for make to print some kind of "percent complete" graph, and that can't be done either for exactly the same reason: make has no idea how far it has to go before it's done, because make doesn't know when it will be done until it already is. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
