Parallel builds of mozilla firefox is disabled due to bug 135420 (http://bugs.gentoo.org/show_bug.cgi?id=135420) which says leave it disabled till upstream fix it properly and closed Upstream.Upstream on the other hand supports parallel builds in places like http://webtools.mozilla.org/build/config.cgi and http://developer.mozilla.org/en/docs/Mozilla_Build_FAQ. Personally i became aware of the problem when i built mozilla firefox for my slower u60 using my larger e4500 and it took alot of time which made me look at processes and noticing make was running with make -j10 -j1 restricting build to serial. Removing -j1 from ebuild and redigesting resulted in alot shorter build and no obvious problems. Following times where obtained with time emerge mozilla-firefox Emergetime -j10 real 69m8.115s user 172m0.190s sys 93m1.840s Emergetime restricted to -j1 real 185m52.092s user 169m10.240s sys 18m40.440s The later also has slight filecache advantage. Attempting to build with -j9 now just to see if uneven -j values crashes it. So far so good I would like that either the restriction is removed or a local use-flag is introduced to work around it. If restriction is removed a warning could be added that parallel builds can fail on this piece of software. Reproducible: Always Steps to Reproduce: 1. Set MAKEOPTS="-jX" where X>1 2. emerge mozilla-firefox Actual Results: mozilla-firefox is built with -j1 Expected Results: mozilla-firefox is built with -jX
I'm looking into it.
This is fixed on: www-client/mozilla-firefox-2.0.0.4 mail-client/mozilla-thunderbird-2.0.0.0 net-libs/xulrunner-1.8.1.4 app-office/mozilla-sunbird-0.3.1 www-client/seamonkey-1.1.2
(In reply to comment #2) > This is fixed on: > net-libs/xulrunner-1.8.1.4 This isn't fixed on net-libs/xulrunner-1.8.1.4 :) .
(In reply to comment #3) > (In reply to comment #2) > > This is fixed on: > > net-libs/xulrunner-1.8.1.4 > > This isn't fixed on net-libs/xulrunner-1.8.1.4 :) . > I tested it but i didn't commit it, thanks for reminding me, fixed.
It seems upstream hasn't really fixed this as it's causing the same problems it did before, I'm reverting these changes to resolve bug 182929.
The mozilla build process has its own 'MOZ_MAKE_FLAGS' in client.mk, I'm wondering if parallel building works better if MAKEOPTS is migrated to MOZ_MAKE_FLAGS (ie, with an 'export MOZ_MAKE_FLAGS="${MAKEOPTS}"' the same way MOZ_CO_PROJECT and such are set) ?
