I think this may no longer a TB-specific problem if my hunch is correct. More at the end.
On 2014/10/12 15:02, ISHIKAWA, Chiaki wrote: > 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. > OK, the following may be of relevant information. When mozilla/js/src is configured during automatic configure after removing the MOZ_OBJ directory, I saw no mention of --with-ccache=/usr/bin/ccache on the command line or for that matter any mention of ccache in the command line. (Excerpt 1 below). I think that is why ccache is not used for the compilation of files below this directory. On the other hand, when js/src/ctypes/libffi is configured (and files below this directory were compiled using ccache), I notice that the compiler command passed to configure as variable (CC and CXX) has /usr/bin/ccache at its front and so ccache is used. (Excerpt 2 below). Excerpt 1: Configuring js/src Note the lack of "ccache" on the command line. [...] configuring in js/src running /bin/sh /REF-COMM-CENTRAL/comm-central/mozilla/js/src/configure --enable-application=mail --enable-gc-zeal --enable-debug-symbols=-gsplit-dwarf --disable-ldap --disable-necko-wifi --enable-tests --disable-gstreamer --enable-debug --enable-shared --enable-official-branding --enable-crashreporter --disable-libjpeg-turbo --enable-default-toolkit=cairo-gtk2 --with-system-ply --disable-necko-wifi --enable-valgrind --enable-optimize=-g -O2 -freorder-blocks --disable-jemalloc --disable-unified-compilation --enable-profiling --with-external-source-dir=/REF-COMM-CENTRAL/comm-central --enable-threadsafe --enable-ctypes --disable-shared-js --disable-export-js --disable-gcgenerational --with-nspr-cflags=-I/REF-OBJ-DIR/objdir-tb3/dist/include/nspr --with-nspr-libs=-L/REF-OBJ-DIR/objdir-tb3/dist/lib -lnspr4 -lplc4 -lplds4 --prefix=/REF-OBJ-DIR/objdir-tb3/dist --cache-file=/REF-OBJ-DIR/objdir-tb3/config.cache loading cache /REF-OBJ-DIR/objdir-tb3/config.cache checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking build system type... x86_64-unknown-linux-gnu [...] Excerpt 2: Configuring js/src/ctypes/libffi Note that CC and CXX contains /usr/bin/ccache at the front. (I think the printing could use quotes so that we would see CC='...' CXX='...' instead of the value without quotes.) BTW, I specify my CC as/usr/bin/gcc-4.9 and with the options: -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 when I configure the source directory. That is why we have CC=/usr/bin/ccache /usr/bin/gcc-4.9 -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 and ditto for CXX.) [...] configuring in js/src/ctypes/libffi running /bin/sh /REF-COMM-CENTRAL/comm-central/mozilla/js/src/ctypes/libffi/configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --disable-shared --enable-static --disable-raw-api --enable-debug --with-pic AS=$(CC) CC=/usr/bin/ccache /usr/bin/gcc-4.9 -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 CXX=/usr/bin/ccache /usr/bin/g++-4.9 -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 CPP=/usr/bin/gcc-4.9 -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG=1 -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -E LD=ld AR=ar RANLIB=ranlib STRIP=strip --cache-file=/REF-OBJ-DIR/objdir-tb3/js/src/ctypes/libffi/config.cache configure: creating cache /REF-OBJ-DIR/objdir-tb3/js/src/ctypes/libffi/config.cache checking build system type... x86_64-unknown-linux-gnu So, I think it is a build system breakage somewhere. Why the difference between the subdirectories of js/src are beyond me. I will file a bugzilla later, but I have no idea which subdirectories are NOT passed proper ccache information during configure. So I will mention only this js/src directory and ask someone in the know to figure the issues out. Has anyone compiling FF notice similar issues? I think this would also affect FF developers. TIA _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
