File paths are way too long about shaderc-rs HOT 6 CLOSED

Yes, agreed. I also noticed this issue on buildbot recently and had a temporary solution (3d6fa5c). Looking for better ways now.

The long path is because both the default Rust target/ directory organization (attaching the super long target\x86_64-pc-windows-msvc\debug\build\shaderc-ceea3062217d891f\out\build component to the path if you build towards x86_64-pc-windows-msvc) and the target names in SPIRV-Tools (spirv-tools-spv-amd-shader-explicit-vertex-parameter). Arguably the first part carries more weight.

Funnily we are in the year of 2019 now, yet still suffer from some limitation from DOS time. MSBuild should really be modernized: dotnet/msbuild#53.

from shaderc-rs.

As a temporary workaround, you can use cargo --target-dir. See .appveyor.yml.

from shaderc-rs.

I've merged #38, which will detect whether Ninja exists in PATH and use it if true. It's pulling in another dependency (which is likely already installed on C++ dev machines), but Ninja is generally faster than MSBuild and does not suffer from MAX_PATH issue.

To make MSBuild work means to trim down the path. As discussed in #33 (comment), neither the default Rust target directory organization nor the SPIRV-Tools target name is easy to trim down for that purpose. And both of them can change again in the future.

from shaderc-rs.

The existence of this workaround should also be explicitly documented in the README.md

from shaderc-rs.

@Lokathor, it's already documented in README with a4f1bcc.

from shaderc-rs.

oh! so it is, foolish me

from shaderc-rs.