Bugzilla Bug 181722

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) ?