Follow-up Comment #3, bug #56484 (project make):
The POSIX standard requires that prerequisites are processed in order; it
says:
> The make utility shall treat all prerequisites as targets themselves and
recursively ensure that they are up-to-date, processing them in the order in
which they appear in the rule.
There are lots of makefiles written to rely on this behavior, that do not
(correctly) support parallelism.
GNU make will also process prerequisites in the same order when parallel jobs
are enabled. Of course, the operating system may allow jobs to finish out of
order (jobs that were started first finish after jobs started second). Also,
if make cannot build target A because one of its prerequisites is still being
built, it can start a later target that would normally not be built until A
completed.
Of course, by adding the -j option you are excusing yourself from strict
adherence to the above POSIX requirement, so it's possible that GNU make could
do something different when -j is in effect. Or some new option could be used
to enable this behavior.
There's only one way I can think of to make this work, that doesn't involve
massive changes. However, even so it's a very large effort, and I have no
plans to work on this myself. Maybe someone else would want to take it on so
I'll leave this open as an enhancement request.
The first problem is that make has no way to determine "was this file changed
after the last build", because make has no idea when the last build happened.
Make doesn't track when it was run: it uses the filesystem's time last
modified value on targets and their prerequisites to determine what's out of
date. Basically you're asking that some prerequisites have a special meaning,
such that if they're newer than the target that gives them a higher priority.
The obvious and simple way to do this is treat the first prerequisite (the one
used for $<) as the special one and say if that prerequisite is newer than the
target then this target should be rebuilt before targets where $< is not
newer.
The second problem is that GNU make does not work by first creating a list of
all the things it needs to rebuild before it builds anything. So there's no
way to take the entire list and re-order it. Instead, make starts with the
first target, looks at its first prerequisite, sees if that needs to be built
and builds it, then looks at the next and builds that, etc. until it finally
discovers there's nothing left to build, then it's done.
The only way this could be done without completely rewriting make's build
algorithm would be for make to walk the dependency graph twice. The first
time through it would rebuild only targets whose initial prerequisite ($<) is
newer. Then when it was done with that, it would go back and walk the whole
graph again, this time building everything else that was out of date.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?56484>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
