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