You can use |mach clobber --full| to remove the incremental cache. It might be worth filing a bug for the large size, my best guess is that we're keeping around items from old compiler versions. It's possible we could do a full clobber of the IC when we detect a new compiler version, but that might not be a great experience for folks testing on different rust versions.
-e On Tue, Aug 20, 2019 at 11:02 AM ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: > On 2019/08/20 14:32, Kris Maglione wrote: > > On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote: > >> On 2019/08/20 9:11, Dave Townsend wrote: > >>> Thanks to a tip I've tracked this down. This seems to only be the > >>> case when > >>> I have sccache enabled. Disabling it gives me nice quick incremental > >>> builds > >>> again. Of course that isn't an ideal solution but it will do for now. > >>> > >>> On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend > >>> <dtowns...@mozilla.com> wrote: > >>> > >>>> For a couple of weeks now I've seen that any attempt to build Firefox, > >>>> even incremental builds seem to rebuild an awful lot of rust code. > >>>> I found > >>>> this in the source which seems to suggest why: > >>>> > https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238. > > >>>> > >>>> But, this means that now an incremental build with a couple of code > >>>> change > >>>> that have no impact on rust is taking upwards of 4 minutes to > >>>> complete in > >>>> comparison to around 40 seconds, and the log file is full of cargo > >>>> output. > >>>> I've heard similar comments from other developers. > >>>> > >>>> This is a pretty big increase in the time to compile and test and is > >>>> really slowing down my work. Is there any way we can avoid this? > >>>> > >>> ____________________________________________ > >> > >> > >> I am using linux for local development and noticed something similar. > >> > >> So I should disable sccache (!?). > > > > For what it's worth, Rust is now configured to use incremental > > compilation, which has its own cache which isn't cleared after > > clobber, so sccache isn't actually needed anymore. Ordinary ccache > > should be sufficient. > > > > > > I was not sure where this incremental compilation cache is located. > Sure enough on my computer it seems to live under > MOZ_OBJ/x86_64-unknown-linux-gnu/debug/incremental > > I have a serious question: does this incremental cache have a control > mechanism to purge old entries? > > I have been hit with file system overflow errors quite frequently since > early summer and I figure > this is due to the bloated > MOZ_OBJ/x86_64-unknown-linux-gnu/debug/incremental directory. > > It is now 26.6 GB with 67840 items according baobab file system usage > monitor. > > 26.6 GB for this incremental cache alone is way too much number that was > suggested by mozilla development document before. > In comparsion, ccache I use is usable with max size of 5GB > as set by > CCACHE_SIZE=5.0GB > in my script. > > On my local PC, I see that the file directory size (with the sizes of > subdirectories added to it) is as follows: > > MOZ_OBJ is 45.8 GB large. (as of now: I had to stop TB compilation due > to the 50 GB smallish partition overflow where this directory is located.) > MOZ_OBJ/x86_64-unknown-linux-gnu/ is 33.9 GB large . > MOZ_OBJ/x86_64-unknown-linux-gnu/debug/ is 33.9 GB large. > I think /debug/ is because I create full debug version of TB locally. > MOZ_OBJ/MOZ_OBJ/x86_64-unknown-linux-gnu/debug/incremental is 26.5 GB > large. > > I need a way to shrink this incremental cache reasonably. > It seems this incremental directory grows without limit. Or, it does not > trim old unusable cache files automatically. > > TIA > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
