build.rs: workaround for windows/vulkan filetracker errors #767
+11
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because of the recent changes (around ~may 14th) to llama.cpp's cmake stuff around vulkan-shaders-gen, it's very easy to create paths longer than the maximum allowed on windows, when building crates that depend on llama-cpp-rs on windows that use the vulkan backend.
Yes, it is possible to change the maximum path length on windows (e.g. the
windows-latest
github actions runner already does this, afaik), but it seems like there are some quirks in MSBuild's FileTracker, that makes it not respect the maximum file path set in the windows registry. I'm by no means a windows expert, but it seems like the rabbit hole goes deep here. (e.g. issue 53 on dotnet/msbuild)To work around this issue, I added some configuration specifically for windows+vulkan builds, that disables the msbuild filetracker thingy. This means that windows vulkan builds re-build things more frequently than strictly necessary - but at least it no longer crashes with (very non-descriptive) errors caused by long paths.
It's kind of a hack, but it makes windows+vulkan builds work in github actions again.