Successful build with 8.3 filename errors beforehand

[jdsanchez]

OS: Windows 11 26100.4349

Couldn't successfully continue the build without enabling 8.3 filenames

Code: Select all

0:12.06 DEBUG: _cc: Trying cl
 0:12.06 ERROR: GetShortPathName returned a long path name. Are 8dot3 filenames
disabled?
 0:12.12 *** Fix above errors and then restart with\
 0:12.12                "c:/mozilla-build/mozmake/mozmake.EXE -f client.mk build
"
 0:12.13 client.mk:375: recipe for target 'configure' failed

Enabled 8.3 filenames using this reference https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/ff621566(v=ws.11)?redirectedfrom=MSDN

However, after enabling it, I had to reinstall Mozilla Build and all prerequisites, such as VS Community, before trying to build again, as the 8.3 setting had not been applied to all the files downloaded before enabling it.

Afterwards, the build was successful.

[Moonchild]

That's an error I personally haven't seen in all my time building, but then again, I tend to install Visual Studio in a short path on a separate volume (because having it in C:\Program Files (x86)\Microsoft\Bla Bla is very unwieldy), probably avoiding some of that, and it seems Windows 10 and before keeps the 8dot3 flag on on at least the system volume, which avoided the issue for me regarding the components of Visual Studio that are always plonked on C:. Apparently, according to the bug pointed out, it's a problem with make that just doesn't handle spaces in file names/paths (especially search paths)...

However, after enabling it, I had to reinstall Mozilla Build and all prerequisites

The problem is that the 8dot3 name on a volume applies at file creation time. Turning 8dot3 name on after the fact does nothing to existing files; those files must be recreated.
Since Windows SDK and the likes installs in a path that has spaces by default, that would need to be recreated.

We really need a way to get rid of this. bug #1323381 has a patch to fix these issues but that was never landed at Mozilla (it quotes links and changes some logic). No idea why they opted to just change the error message to give more details instead of fixing it in the build system...

The annoying part is that to test if that patch works, you'd need to first have a broken system -- and I'm not inclined to purposefully break my setup, so it'd need to be done in a VM or something making this quite a bit more involved.