Hi all, Recently I tried to build Firefox on cloud, and noticed that building Rust dependencies is now a significant part of it. Another thing I noticed is that, we have lots of duplicate Rust dependencies.
I scanned Cargo.lock in the root and found that we have: * 2 versions of block-buffer (0.3.3, 0.7.0) * 2 versions of byte-tools (0.2.0, 0.3.0) * 2 versions of crossbeam-deque (0.2.0, 0.3.1) * 2 versions of crossbeam-epoch (0.3.1, 0.4.3) * 3 versions of crossbeam-utils (0.2.2, 0.3.2, 0.6.3) * 2 versions of digest (0.7.6, 0.8.0) * 2 versions of generic-array (0.9.0, 0.12.0) * 2 versions of lazycell (0.4.0, 0.6.0) * 2 versions of log (0.3.9, 0.4.6) * 2 versions of memchr (1.0.2, 2.0.1) * 2 versions of memmap (0.5.2, 0.6.2) * 2 versions of nom (3.2.1, 4.1.1) * 2 versions of num-traits (0.1.43, 0.2.6) * 2 versions of proc-macro2 (0.3.5, 0.4.24) * 2 versions of quote (0.5.2, 0.6.10) * 2 versions of rand (0.3.22, 0.4.3) * 2 versions of regex (0.2.2, 1.0.0) * 2 versions of regex-syntax (0.4.1, 0.6.0) * 2 versions of semver (0.6.0, 0.9.0) * 2 versions of sha2 (0.7.1, 0.8.0) * 2 versions of slab (0.3.0, 0.4.1) * 2 versions of strsim (0.6.0, 0.7.0) * 3 versions of syn (0.13.1, 0.14.6, 0.15.24) * 2 versions of uuid (0.6.5, 0.7.1) * 2 versions of winapi (0.2.8, 0.3.6) Although these duplicate dependencies may not go into the final binary, they are still things which can slow down the build. In this list, I would suspect crates like nom, regex, and syn could take significant time to build for each version. Servo has a policy banning duplicate dependencies with a whitelist, and such list currently has: * base64 * block-buffer * byte-tools * crossbeam-deque * crossbeam-epoch * crossbeam-utils * digest * generic-array * rand * unicase * winapi and they had a tradition (in my opinion) to help pushing the ecosystem forward using new versions of dependencies. Should we have some kind of policy to address duplicate dependencies in Gecko as well? Maybe I'm missing something but I don't think I'm aware of any previous discussion about this. - Xidorn _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
