SCons: Silence redundant MSVC output

[Repiteo]

"Closes" #72246. Technically, that issue is already closed & marked as "not planned", as this is actually an msvc bug¹. Nonetheless, I've figured out a workaround for the majority of the issues caused by this: redirecting the stdout to NULL where supported. This works like a charm when compiling objects and resources, effectively reducing output bloat by half! I haven't found a workaround for the linker, but there's only ever less than a handful of files linked in a given build, so it's much less of a concern. In practice, the output logs are significantly cleaner & much more closely resemble gcc/clang, and preserving stderr allows potential errors to still be caught and logged as before

Before:

[  9%] Compiling thirdparty\libvorbis\sharedbook.c ...
mapping0.c
[  9%] Compiling thirdparty\libvorbis\smallft.c ...
mdct.c
[  9%] Compiling thirdparty\libvorbis\synthesis.c ...
psy.c
registry.c
sharedbook.c
res0.c
smallft.c
synthesis.c
[  9%] Compiling modules\msdfgen\register_types.cpp ...
[  9%] Compiling thirdparty\libvorbis\vorbisfile.c ...
[  9%] Compiling thirdparty\libvorbis\window.c ...

After:

[  9%] Compiling thirdparty\libvorbis\res0.c ...
[  9%] Compiling thirdparty\libvorbis\sharedbook.c ...
[  9%] Compiling thirdparty\libvorbis\smallft.c ...
[  9%] Compiling thirdparty\libvorbis\synthesis.c ...
[  9%] Compiling modules\theora\video_stream_theora.cpp ...
[  9%] Compiling modules\theora\register_types.cpp ...
[  9%] Compiling modules\msdfgen\register_types.cpp ...
[  9%] Compiling thirdparty\libvorbis\vorbisfile.c ...
[  9%] Compiling thirdparty\libvorbis\window.c ...
[ 10%] Compiling thirdparty\astcenc\astcenc_averages_and_directions.cpp ...
[ 10%] Compiling thirdparty\astcenc\astcenc_block_sizes.cpp ...
[ 10%] Compiling thirdparty\astcenc\astcenc_color_quantize.cpp ...
[ 10%] Compiling thirdparty\astcenc\astcenc_color_unquantize.cpp ...
[ 10%] Compiling thirdparty\astcenc\astcenc_compress_symbolic.cpp ...

Footnotes

1. https://developercommunity.visualstudio.com/t/allow-having-clexe-not-print-the-compiled-source-f/717761 ↩

[Repiteo]

Hmm, looks like the build actions have some discrepancy to locally building, causing the output to fail. Looking into this now

[Repiteo]

Alright, figured it out! The method worked if the command wasn't redirected to a temp file; Otherwise, the > NUL command failed to process as expected. This would also explain why linking didn't seem to work, as it was always calling to a tempfile as well. This is now dealt with in two ways:

1. Increased the MAXLINELENGTH environment variable to 8192. It's normally set to 2048 for Windows, but it can be quadrupled to 8192 for Vista and later, which will always be applicable for us. It seems that there's not a situation where that increased line length is exceeded for objects/links.

2. Remove > NUL from the arguments if taken to a tempfile. In the offchance that a commandline does exceed the above limit, we'll just not bother at all and revert back to the old behavior, ensuring that the build will process & succeed no matter what.

Unfortunately not the silver-bullet solution I was hoping for, as there's now a scenario where an obscenely long commandline will have the old behavior. But in practice, it shouldn't affect us at all, and as a bonus we now have linker output suppressed as well!

[Calinou]

Tested locally (with progress=no and rebased on top of master dad6c77), it works as expected on Windows 11 23H2 + Visual Studio 2022.

It also works when applied at the same time as #85153.

[akien-mga]

Thanks!