I did a non-unified build and saw the expected failure.
This is a summary of what I saw.
Background:
I may need to modify and debug basic I/O routines on local PC, and so
want to avoid unnecessary compilation. I use ccache locally to make
sure I can avoid re-compilation of touched but not modified C++ source
files (files get touched and remain unmodified when I execute
"hg qpop" and "hg qpush" in successions to work on different patches.
Without ccache, I have to compile many files. ccache helps a lot.)
There is a different perspective on unified compilation.
Compiler farm users:
One time fast compilation　is very important.
So unified compilation is a win.
(I suspect precompiled headers, -pch, would be a good win, too.)
Developers who repeats "edit a small set of files, compile and link"
many times on local PC:
He/she may modify only a few files and want quick
turn around of the compile of a few files and link time.
Unified compilation actually compiles more lines than he/she wants
(because of the extra source lines included in unified source files
in which his/her modified files are also included.
(Correct? Am I missing something here?)
So he/she may not like unified compilation in such scenario.
He/she can live with a long initial compilation time of whole tree
after refreshing the source. He/she can do that overnight and
continue edit a few files, compile and link the next day, and there
the quick turn around of the compilation of the exactly the
modified files will be appreciated.
(actually I think I saw a slow down of ccache due to the more lines
of input code checked for identity.)
With this in mind, I checked whether the suggestion from Mike Hommey
on Jan 17 (JST) to disable unified compilation works to produce a
successful non-unified build.
>> Can you think of something better/more obvious?
>
>Add this to toplevel moz.build:
>
>FILES_PER_UNIFIED_FILE = 1
>export('FILES_PER_UNIFIED_FILE')
>
The build breaks as was predicted in the mailing list.
The tree is already rotten in the sense of correct INDIVIDUAL C++ source
files.
19 files fail to compile due to missing or incorrectly ordered (?)
declarations (I think).
(This is what was observed during C-C thunderbird build.)
Compilation fails for the following files.
mozilla/dom/base/DOMException.cpp
mozilla/dom/fetch/Request.cpp
mozilla/dom/ipc/TabChild.cpp
mozilla/dom/ipc/nsIContentChild.cpp
mozilla/dom/media/MediaManager.cpp
mozilla/dom/media/eme/MediaKeyStatusMap.cpp
mozilla/gfx/layers/apz/util/APZCCallbackHelper.cpp
mozilla/gfx/layers/apz/util/ChromeProcessController.cpp
mozilla/gfx/thebes/gfxFont.cpp
mozilla/gfx/thebes/gfxFontEntry.cpp
mozilla/gfx/thebes/gfxHarfBuzzShaper.cpp
mozilla/js/ipc/JavaScriptShared.cpp
mozilla/layout/xul/nsResizerFrame.cpp
mozilla/media/libstagefright/binding/SinfParser.cpp
mozilla/netwerk/base/nsBaseChannel.cpp
mozilla/tools/profiler/ProfileEntry.cpp
mozilla/widget/VsyncDispatcher.cpp
mozilla/xpcom/build/MainThreadIOLogger.cpp
mozilla/intl/icu/source/i18n/rbnf.cpp
<--- This may have failed because I forced "-DDEBUG" on
compiler command line and a buggy code inside #if DEBUG,#endif
gets compiled. So probably not related to unified compilation
at all.
After seeing this failure, I think the following is what a developer
tinkering with edit, compile and link cycle on a local PC can do to
minimize unnecessary compilation of extra lines:
Do a unified compilation across the tree, but maybe enables
FILES_PER_UNIFIED_FILE=1 in moz.build of the particular directory
where he/she needs to edit files, to avoid unnecessary compilation (of
included files).
And if he/she needs to work in a directory where a few files (among 19
files above) don't compile, he/she has to figure out what the exact
cause of the compilation and fix it to use a compile-a-file-at-a-time
compilation scheme if that is preferred.
He/she better submit patches to keep the tree in good shape.
In my case, I may have to modify a few files under
mozilla/netwerk/base/ in order to debug TB's failure to use buffered
output during message downloading. nsBaseChannel.cpp fails to compile
under that directory. It is not quite easy to figure out whether the
cause of the failure can be figured out by myself.
On the other hand, if the build result in only one unified-compilation
(if there is only one file being modified), then the absolute
compilation time is not that long. So a developer who performs local
edit, compile and like cycles often can live with it hopefully.
Any better suggestion?
If everybody has a VERY FAST CPU LOCALLY, maybe this is not an issue...
TIA
PS: I can send the compilation log on request.
The compilation problems seem to be easy to fix for someone who knows
the details of header inclusion relationship, etc. This is my optimistic
assumption, but in reality, it may be very complex.
PPS: I wonder if the source tree is re-organized for
unified-compilation, using -pch to use pre-compiled headers
now is now a very viable option. Isn't it?
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
