Update of bug #58735 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Operating System:
Follow-up Comment #7, bug #58735 (project make):
A fix for the "try to rebuild included makefiles in reverse order" issue has
been pushed to Git and will be in the next release.
Thanks for reporting!
___
Reply to this item at:
Follow-up Comment #6, bug #58735 (project make):
I just want to be clear: changing make to allow it to be able to rebuild
makefiles incrementally is not just a breaking change, it is also a sizeable
development effort.
Today GNU make works in three discrete stages: first it reads all makefiles,
t
Follow-up Comment #5, bug #58735 (project make):
> If I provide more dependency information, gmake runs more commands in
parallel when in parallel mode and this will cause more problems since only
one of these commands needs to be run.
As discussed in the other bug, the right answer to this probl
Follow-up Comment #4, bug #58735 (project make):
If I provide more dependency information, gmake runs more commands in parallel
when in parallel mode and this will cause more problems since only one of
these commands needs to be run.
So this is also a problem that is related to an unhappy combin
Update of bug #58735 (project make):
Summary: if depending on include, gmake does not execute
commands for out of date targets in the right order => When rebuilding
makefiles, make tries them in reverse order
___
Follow
Maybe implement $(reverse)
A = a b c d e
x:
echo $(reverse, $A)
Would give
e d c b a
or at least at
(Info-search "reverse")
This macro simply reverses its arguments:
reverse = $(2) $(1)
foo = $(call reverse,a,b)
mention how to reverse a
use "a" finished
>> fast, before "b" actually needed to use it's result.
>
>> It might be interesting to have a make flag that would reverse the order
>> in which dependencies are considered, this will catch really fast
>> missing dependencies even w
ome time ago:
>
> > I've run into situations where given:
>
> > foo: a b c
>
> > and "b" was missing a dependency on "a".
>
> > The above did not fail with parallel make for years because "a" finished
> > fast, before &quo
lly needed to use it's result.
> It might be interesting to have a make flag that would reverse the order
> in which dependencies are considered, this will catch really fast
> missing dependencies even when building with "make -j1".
> Is something like th
> It might be interesting to have a make flag that would reverse the order
> in which dependencies are considered,
... or indeed randomise the order, so that repeated testing would
routinely catch any un-noticed dependencies.
Does anything actually specify that order of prerequisites in
I've run into situations where given:
foo: a b c
and "b" was missing a dependency on "a".
The above did not fail with parallel make for years because "a" finished
fast, before "b" actually needed to use it's result.
It might be interesting t
12 matches
Mail list logo
