Bug 211943 – REGRESSION(r261533): Breaks parallel builds [GTK]

• Component: New Bugs
• Status: RESOLVED INVALID

[Jim Mason]

r261533 breaks parallel builds with -j4.  Builds with -j1 complete normally.

The error is:

    make[3]: *** No rule to make target 'DerivedSources/WebCore/JSBlob.h', needed by 'DerivedSources/ForwardingHeaders/WebCore/JSBlob.h'.  Stop.
    make[3]: *** Waiting for unfinished jobs....
    make[3]: Leaving directory '/build/rtutils/components/desktop/webkitgtk4-dev/build/amd64'
    make[2]: *** [CMakeFiles/Makefile2:1024: Source/WebCore/CMakeFiles/WebCore_CopyPrivateHeaders.dir/all] Error 2
    make[2]: *** Waiting for unfinished jobs....

I am building the GTK port.

[Jim Mason]

For what it is worth, building with -j4 is working for me as of this moment (r261738).  My -j4 builds were still breaking as of about r261690.

Not sure if it has been fixed, or if the race condition is still present and I am just getting lucky now...

[Jim Mason]

(In reply to Jim Mason from comment #1)
> Not sure if it has been fixed, or if the race condition is still present and
> I am just getting lucky now...

It seems the latter:  Parallel builds used to complete in a deterministic way for me; that is to say, they would build to completion 100% of the time, in absence of an actual problem.

Now I am finding that otherwise good builds will sometimes, but not always, terminate prematurely due to the parallel build problem.  I can just re-make, and on the second or third go, get lucky.

Ideally, we would figure out what the dependency is and ensure it is explicitly specified so that parallel builds will always complete in a deterministic way.

As I am able to reproduce on a farily consistent basis, if there is anything I can do to assist, please let me know.

[Carlos Alberto Lopez Perez]

(In reply to Jim Mason from comment #1)
> For what it is worth, building with -j4 is working for me as of this moment
> (r261738).  My -j4 builds were still breaking as of about r261690.
> 
> Not sure if it has been fixed, or if the race condition is still present and
> I am just getting lucky now...

Can you reproduce this with ninja instead of make?

To use ninja pass the parameters "-G Ninja" to CMake and then use "ninja" / "ninja install" instead of "make" / "make install" (you need to start a new clean build if you change from make to ninja)

[Jim Mason]

(In reply to Carlos Alberto Lopez Perez from comment #3)
> Can you reproduce this with ninja instead of make?

Thanks for the suggestion!

So far, so good with ninja.  I've already run about 6 ninja builds; all have completed successfully.  Make would have failed already.

I will continue to use ninja in the coming days/week and post here any update.  If the dependency problem should manifest itself with ninja, then I would expect to see it by the end of the week.

[Jim Mason]

(In reply to Jim Mason from comment #4)
> (In reply to Carlos Alberto Lopez Perez from comment #3)
> > Can you reproduce this with ninja instead of make?
> 
> Thanks for the suggestion!
> 
> So far, so good with ninja.  I've already run about 6 ninja builds; all have
> completed successfully.  Make would have failed already.
> 
> I will continue to use ninja in the coming days/week and post here any
> update.  If the dependency problem should manifest itself with ninja, then I
> would expect to see it by the end of the week.

Thanks for the advice!

Since May, I have made dozens if not hundreds of builds with ninja and all have been successful.

Closing as I can no longer reproduce.