On Wed, 2009-02-04 at 10:24 -0800, Philip Guenther wrote: > Those are just the sort of items I would consider if this was my > project; Paul and the other developers may have completely different > criteria in mind, but I would be surprised if they didn't overlap > some.
I think all of Philip's points are appropriate. To my mind the only real advantage to doing this as a built-in-to-make facility vs. just having people script it, as Noah did, is if we can work out a way to make it faster by being built in. The only way I can see that happening, realistically, is to avoid the read step and, second and subsequent times through, we would start after we've already read the makefiles and before we start trying to build the goals. However, I think this would be a lot of effort; make is not designed to be "clean" in that way; as far as I know there's no simple way to get back to that fresh, "just read" state (no "Irish Spring" for make internals! :-)). Make really just exits when its done and lets the system recover all its resources, rather than spending time running around freeing things etc. So offhand I think this is a lot of work for not a huge amount of gain. Anyway that's my $0.02. _______________________________________________ Bug-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-make
