Hi,
I am using ccache for local compilation of comm-central
TB.
After the checkout a few hours ago, and tinkering
with my local hg patch queues,
I noticed some files are NOT compiled using ccache any more.
(I was debugging a local ccache that groks -gsplit-dwarf option
to gcc. This option and use of GNU ld.gold makes linking rather fast.)
I have not figured out which files are not compiled using ccache
completely, but, as starters,
the files under comm-central/mozilla/js/src/*
such as jsobj.cpp and friends,
and the files below such as comm-central/mozilla/js/src/vm/*
such as CallNonGenericMethod.o and friends
are compiled without using ccache :-(
(I see the name of .o files printed out and I can link the
final TB. So the build as a whole works: I use mk_add_options
MOZ_MAKE_FLAGS="-s" to make the build log terse.)
In the ccache log, compilation of these files mentioned above is not
recorded at all.
So presumably somehow the ccache is not invoked for these files.
(But some files under mozilla/js/ subdirectories are compiled using
ccache. See below.)
My question is:
Is this omission of ccache usage intentional for these files?
In the following, I list files under mozilla/js directories
which are still compiled using ccache (and thus the source file
information was recorded in ccache log.)
Th list is a sorted list in alphabetic order.
Their order of compilation may differ.
Note 1:
I took out the common path prefix which is
/REF-COMM-CENTRAL/comm-central which is my TOPSRCDIR directory and
replaced it with ".".
Note 2:
But note that there is a strange path
at the end, which is
/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/dom_quickstubs.cpp
/REF-OBJ-DIR/objedir-tb3 is my MOZ_OBJ directory.
So it looks that this dom-quickstubs.cpp is
COPIED to MOZ_OBJ/js/xpconnect/src/ directory
whereas other source files remain in the original source directory
and some make hackery (VPATH maybe) makes the references to the original
source files
when the compilation proceed in MOZ_OBJ directory.
E.g.: files under ./mozilla/js/ directory that are compiled using ccache
[and recorded in ccache log].
"..." means that I omit the repetition of files under the same directory.
./mozilla/js/ductwork/debugger/JSDebugger.cpp
./mozilla/js/ipc/JavaScriptChild.cpp
./mozilla/js/ipc/JavaScriptParent.cpp
./mozilla/js/ipc/JavaScriptShared.cpp
./mozilla/js/ipc/WrapperAnswer.cpp
./mozilla/js/ipc/WrapperOwner.cpp
./mozilla/js/src/ctypes/libffi/src/closures.c
./mozilla/js/src/ctypes/libffi/src/debug.c
./mozilla/js/src/ctypes/libffi/src/java_raw_api.c
...
./mozilla/js/src/ctypes/libffi/src/x86/ffi64.c
./mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp
./mozilla/js/xpconnect/loader/mozJSLoaderUtils.cpp
./mozilla/js/xpconnect/loader/mozJSSubScriptLoader.cpp
./mozilla/js/xpconnect/shell/xpcshell.cpp
./mozilla/js/xpconnect/src/ExportHelpers.cpp
./mozilla/js/xpconnect/src/Sandbox.cpp
./mozilla/js/xpconnect/src/XPCCallContext.cpp
./mozilla/js/xpconnect/src/XPCComponents.cpp
./mozilla/js/xpconnect/src/XPCContext.cpp
...
./mozilla/js/xpconnect/src/XPCWrapper.cpp
./mozilla/js/xpconnect/src/nsScriptError.cpp
./mozilla/js/xpconnect/src/nsXPConnect.cpp
./mozilla/js/xpconnect/tests/components/native/xpctest_attributes.cpp
./mozilla/js/xpconnect/tests/components/native/xpctest_module.cpp
./mozilla/js/xpconnect/tests/components/native/xpctest_params.cpp
./mozilla/js/xpconnect/wrappers/AccessCheck.cpp
./mozilla/js/xpconnect/wrappers/AddonWrapper.cpp
./mozilla/js/xpconnect/wrappers/ChromeObjectWrapper.cpp
./mozilla/js/xpconnect/wrappers/FilteringWrapper.cpp
./mozilla/js/xpconnect/wrappers/WaiveXrayWrapper.cpp
./mozilla/js/xpconnect/wrappers/WrapperFactory.cpp
. /mozilla/js/xpconnect/wrappers/XrayWrapper.cpp
/REF-OBJ-DIR/objdir-tb3/js/xpconnect/src/dom_quickstubs.cpp
On a not so powerful PC at hand, not using ccache is
a grave problem.
I push and pop hg patch queues often and
such qpush/qpop re-invokes the compilation of files of which mtime only
are changed (the contents remain intact).
ccache saves the day by not invoking the code generation path of the
compilation.
So, if there is no compelling reason for not using ccache for files under
mozilla/js/ and its subdirectories (some directories use ccache as seen
from above), I would like to see the ccache compilation restored.
Yes, I think jsobj.cpp and friends were compiled using ccache before.
But I don't know exactly when ccache became ineffective for these files.
I would not have realized this problem unless I was hacking modified
ccache to make sure it was working well.
TIA
PS: Despite I am using a local hacked version of ccache, I doubt if
this is the cause of this problem.
I have been using the series of locally hacked ccache versions,
and it has performed well: I have been linking C-C TB for about a year
and more successfully.
PPS: Come to think of it, I am using Debian GNU/Linux, and
I remember reading something about upcoming GNU Make
changing behavior very slightly to conform to the latest POSIX standard
in Debian's release note.
That *may* explain the change in behavior.
But someone familiar with the build process and/or
mozilla/js source tree needs to take a look at to find out the root cause.
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
