Re: Must we rebuild all our rust code constantly?
On 2019-08-19 8:11 p.m., 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. What's your sccache version? I think you may be hitting the following sccache bug which has been fixed already: https://github.com/mozilla/sccache/issues/436 I'm using sccache 0.2.9 and I don't see rust code rebuilding constantly. Markus ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Must we rebuild all our rust code constantly?
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 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 > >>> 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
Re: Must we rebuild all our rust code constantly?
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 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
Intent to deprecate: mathspace names for MathML lengths
Hi,
In bug 1574750, I intend to deprecate mathspace names for MathML length
values ("thinmathspace", "mediummathspace", "thickmathspace", etc) which
only have suggested values [1].
The MathML CG agreed to remove them from MathML Core as they can be
replaced with equivalent em values [2]. However, they have been
implemented in both WebKit and Gecko and some MathML content & tools use
them, so we will need to be careful. For now, they will only be disabled
in nightly build.
[1] https://www.w3.org/TR/MathML3/chapter2.html#type.namedspace
[2]
https://github.com/mathml-refresh/mathml/issues/75#issuecomment-523016332
--
Frédéric Wang
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
