compnerd wrote: The patch is meant to support the following pattern (which IMO is actually the proper way to deal with the path canonicalisation):
```cmd subst X: %UserProfile%\SourceCache X: cmake -B X:\b -G Ninja -S llvm-project\llvm ninja -C \b ``` Everything is being built in `S:`, there is no reason that the path should be "canonicalised" to `%UserProfile%\SourceCache\llvm-project\llvm\...` instead of `X:\llvm-project` which is what you told the tools the path is. I do not remember the details off hand, but IIRC, the symbolic link evaluation would implicitly traverse the substitution and give you the path of the storage rather than the actual disk path. Unlikely Unix, Windows does not have a single path tree and therefore the assumptions around paths do not hold up nearly as well in clang. This isn't a higher level construction issue - the problem is the path representation in the internals of clang. It should be able to remember that the paths we are working with are based on a particular drive rather than trying to create a Unix-like approach of a singular path tree. I do not know if there is an API that will let you resolve a path into a particular drive, but if so, that would likely be the proper tool to use here. https://github.com/llvm/llvm-project/pull/139739 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
