Re: intermediate targets not working as expected

[gmake]

On Mon, 31 Jul 2006, Paul D. Smith wrote:

> All that you say is true, it COULD be done that way.
>
> But, that's not the way make works.

Mark it as a long-term enhancement request, then :)

> That's how make works; that's how all make programs I'm aware of have
> always worked.

GNU make is already far enhanced over "standard" makes, that I'm surprised
you're still referring to them as a guide for internal make design, and
not just for compatibility purposes.

> 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.

A "percent complete" graph would be meaningless without information about
how long it takes to build each target, which would require either
profiling information collected by make during prior builds, or timing
information supplied by the user. It would also be platform-dependent.

So many "percent complete" graphs, such as in software installs, spend a
disproportionate amount of time in the last few percent, that they are of
no help at all.

No, I would not ask for that, not unless it went all out and included a
"make profiler". Simply counting the targets and printing the % targets
completed assumes that all targets take an equal time to build, which is
almost never true. It needs to be weighed by the time each target takes.

If you did add make profiling, however, then combined with dependence
analysis, you could better optimize parallel makes. Right now parallel
make does well with a large number of independent targets, because on
average the job server is kept busy all the time. But when the number of
targets is small or there are a lot of dependencies, then parallel make
could use profiling data combined with dependence analysis, to better
schedule targets.

Thanks,
Lee