On 2019/12/28 10:20, Otto Moerbeek wrote:
> On Fri, Dec 27, 2019 at 10:20:35AM -0700, Stuart Henderson wrote:
> 
> > CVSROOT:    /cvs
> > Module name:        ports
> > Changes by: [email protected]   2019/12/27 10:20:35
> > 
> > Modified files:
> >     x11/gnome/bijiben: Makefile 
> >     x11/gnome/mutter: Makefile 
> >     x11/gnome/recipes: Makefile 
> >     x11/gnome/shell: Makefile 
> >     x11/gnome/tracker: Makefile 
> > 
> > Log message:
> > Some GNOME ports had pre-build stages to cope with random build ordering
> > done by devel/ninja. Remove them as they are no longer necessary now
> > that kurt@ has modified ninja to use a deque rather than using a build
> > order dependent on pointer addresses (which due to our malloc were
> > randomised).  ok ajacoutot@
> > 
> 
> I like to stress that the ninja "fix" is hiding dependency problems.
> Randomization of heap addresses should not have an impact. I do
> understand this is needed atm to get workable bulk builds, but this
> commit message sends the message" randomizatioon is bad because it
> breaks things". 
> 
> In my view, randomizaion is good *because* it breaks (already broken)
> things.
> 
>       -Otto
> 

Realistically these will never get fixed unless upstream ninja has a
"build in random order" mode that is frequently used (this was proposed
in https://github.com/ninja-build/ninja/issues/232#issue-3475124)
because users on other OS just don't see any problems.

The above ports were persistent cases but I have been seeing random
failures due to this in nearly every bulk build (the machines are
continually building, so this is 3 or 4 times a week).

The lines removed in the above commit include links to PRs in GNOME
that have been open for ages with no activity. I think robert@ has
had similar success (i.e. none) in getting these fixed in chromium
too. Unless upstream developers have a way to see the problems for
themselves on other OS they are understandably treated as quite
low priority (often you can just restart the build and everything
works).

There is another issue with the randomisation - for "real" build
failures that start to appear after some successful builds (often due
to either changes in base that broke ports, or builds which vary
depending on what other software was installed) one of the most
useful tools for figuring out the problem is diffing build logs
from a successful build. That's no use with random build ordering.

Reply via email to