AUTOMATE GSPLIT 64 BIT
It seems to work well, cutting down the compile and link step into 2 minutes range (under 64 bit linux, and I disabled audio-related extension for thunderbird) except: I have been using -gsplit-dwarf in my local build of comm-central thunderbifd for a while with the modified CCACHE that supports split dwarf files. This speed-up by -gsplit-dwarf is a killer for local build. Since my main target is thunderbird that runs in 32bit mode, I am hesitant to move to 64 bits.) My CPU, a couple of generations architecture P620, 32bit memory space, and virtual environment seems to be the speed limit now.
AUTOMATE GSPLIT 32 BIT
Has cut down my link time of libxul from somewhere near 5 minutes to 1m30s range (on a 32 bit linux that runs under VMPlayer environment.
These operations touch files and force re-compilation even though the final file content is the same (I thought the operations preserve mtime, but seem not to.) Popping patches and pushing patches again. Sometimes unwanted recompilation of files, which seemed unwarranted still happen.Īlso, using mercurial with many local patches, sometimes, I find myself In a real world, due to many configuration issues, still being sorted out, In a perfect world, there is no unnecessary recompilation. Some people may wonder why ccache is useful? I think it works well (and check the operation by looking at the log), but who knows what bug it may still have. We need more testers for this ccache version. (You have to have up-to-date binutils: objcopy that understands -extract-dwo, for example. The only thing I have not tried is to debug the final binary using GDB.
> I don't know how well they work, but we could build and provide binaries, and add a test whether ccache supports the dwo files.Īctually, I have been using this version of ccache on my local PC for a few days, and it seems to work well. Note that a mozilla contributor has submitted patches to.
0 kommentar(er)
