I have noticed for months that when building Firefox, sometimes configure
will run when it shouldn’t, e.g. when I haven’t changed any makefiles or other build system files. This is annoying, because it increases the time taken for a complete no-change build on my Linux box from ~50 seconds to ~70 seconds. And it happens reasonable frequently, but I haven’t been able to reproduce it reliably.
Until yesterday, that is! I realized it happened reliably if I alternated building two different objdirs (e.g. debug and opt). Once I could reproduce it reliably, it wasn’t hard to use make’s -d
option to find out what was causing configure
to re-run. The answer was a file called $(topsrcdir)/.mozconfig.mk
. Because it is put in $(topsrcdir)
instead of $(objdir)
, the building of one objdir can affect the building of another objdir.
The fix was pretty easy — it’s hard to move .mozconfig.mk
out of $(topsrcdir)
, but there’s no good reason to re-run configure
every time it changes, because it doesn’t contain anything that affects configure
. So it was a one-line change in clienk.mk
.
Kyle Huey tells me this bug has been present since 2000!
9 replies on “A fix for an 11-year-old bug in the build system”
How do you get such great build time? 🙂 I understand it is for Firefox. Do you get libxul rebuilt every time even without anything changed in the code? I build Thunderbird and it takes about 5-10 minutes every time. Because I get a rebuild (relink) of libxul every time, probably due to bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=712785.
Is the situation better in Firefox?
I’ve never built Thunderbird, but I expect it’s not that different to Firefox.
My secrets: I’m on Linux, I have a fast (i7) machine with 16GB of RAM, and I use ‘gold’ as my linker.
11 years was a lower bound 😉
That build time has to be using a different compiler than GCC.
It’s with GCC+gold. I have a fast machine, see my response to aceman above.
Hugs.
For all those asking about how to get faster build times on Linux, make sure you’ve got ccache installed, and use:
ac_add_options –with-ccache
With ccache, if I’ve previously done a build on the same source, I can rm -rf my objdir and build from scratch in ~6 minutes on my Core 2 Quad.
Is this option needed even when ccache is enabled globally (symlinking gcc -> ccache, etc.) ? But even ccache will not help when just linking libxul is taking 1,5 minutes. Why it is always relinked (some included files must have changed), I must find out.
Hey, the offending bugs are fixed and a rebuild without any changes now does no longer relink libxul for me! So it now takes 66secs for me!