Mike Hommey wrote:

Secondly, the build system recently grew a new build-time option to help 
determine why something is being recompiled (bug 903385). I'm sure some have 
tried to used make -d for that, and noticed that on top of being heavily 
verbose, it also breaks the build in some places. You can now a build with 
REBUILD_CHECK=1, and when compiled objects, libraries or programs are rebuilt, 
the build system will tell you why, which is helpful to e.g. find out why 
you're rebuilding all of js and webrtc while you changed nothing there.

Please note this does only work for objects, libraries and programs compiled 
for js and gecko, not for chrome files, headers, or for nspr, nss and some 
other third-party code.

You can set REBUILD_CHECK=1 this way:
 - with mach: REBUILD_CHECK=1 mach build
 - with client.mk: make -f client.mk REBUILD_CHECK=1
This doesn't work very well on Windows. Some of the DLLs link to DirectX and the dependencies somehow make it from $(OS_LIBS) into $^ (I couldn't work out how that magic happens). Unfortunately the DirectX path contains shell metacharacters and so can't be passed to a pymake builtin. I tried to shell out to python but I then I ran into a vague Windows error 87. What I ended up doing is changing the definition of REPORT_BUILD to $(info $@ depends on $(notdir $(subst \,/,$?))) (yes, pymake can't notdir a \-separated path...) which doesn't mention deleted files but presumably some other file had to be modified to stop the compilation trying to use the now deleted file.

There was one other thing I noticed, and that's the reporting and compilations don't match up - you'll see a bunch of reports and then the compilation output. I tried using @echo instead of $(info) but it didn't seem to make any difference.

--
Warning: May contain traces of nuts.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to