building Servo exceeds ecryptfs's limits on file name length

[Max-E]

Operating System
This is 64-bit LInux Mint 18, corresponding to Ubuntu 16.04. It was set up with an encrypted home directory using ecryptfs. It's been a while since I set this OS up, but as I recall I just checked the checkbox to create an encrypted home partition and used the default configuration from the operating system installer.

To Reproduce
I installed rustup using the automatic shell script, installed the additional dependencies listed here: https://github.com/servo/servo/blob/master/README.md#on-debian-based-linuxes (correcting the ssl dependency for pre-2017 Ubuntu versions) cloned Servo, and ran ./mach build --dev. That's it. The specific git hash I tried to build was 7b92eb9.

Full command line output of the compile attempt
First attempt:
https://pastebin.com/h2zZwreV
Running again with mach build --dev -v
https://pastebin.com/fMQt2j56
The weird thing is, even in the verbose output, I don't see any file names that look too long. So if there's anything I can do to get more verbose logs, etc., or any troubleshooting steps to try, to make this easier to track down, please do let me know. You can also ask me to join IRC if that's a more convenient way to ask me followup questions, but I won't be available during normal business hours.

Ecryptfs and its restrictions on file names
According to an upstream ecryptfs developer, it's best to keep file names shorter than 140 characters, instead of the native 255 character limit. See: https://unix.stackexchange.com/a/32834 As far as I can tell (I have tested this experimentally,) this restriction does not apply to the total length of the path, only to the name of each inode (the name of each individual directory or file.) So trying to compile from a shorter-named directory is not going to make a difference.

[SimonSapin]

The next compiler upgrade should pick up rust-lang/rust#47186 and help with this. In the meantime, try running with a CARGO_INCREMENTAL=0 environment variable or configuring incremental = false in .servobuild (copied from servobuild.example).

[Max-E]

Thanks for replying so promptly! Unfortunately, this workaround does not appear to have worked: https://pastebin.com/cFLnZW3P still failing on the constellation step.

[SimonSapin]

Ah, incremental became the default in Cargo, so merely not setting CARGO_INCREMENTAL=1 is not enough anymore. #19763 should fix this. Try with that branch or with CARGO_INCREMENTAL=0 on the command-line?

[Max-E]

Yes! The environment variable worked!

Wow, the documentation wasn't kidding about the debug build being slow. Time to repeat that process for a release build I think.

[SimonSapin]

#19764 has landed. Update from master and try again with incremental?

[Max-E]

Yep. I ran mach clean, cleared the environment variable, deleted my .servobuild, updated from git, and now both the debug and release builds are working fine.