Skip to content

Conversation

@ChrisDenton
Copy link
Member

When a path is canonicalized on Windows, a \\?\ prefix is used. However, it appears that cmake can have problems with that. This simply attempts to remove the prefix as we do still want to use absolute path here due to #200 cc @tgross35.

Fixes #258

When a path is canonicalized on Windows, a `\\?\` prefix is used. However, it appears at least some versions of cmake can have problems with that.
@tgross35
Copy link
Contributor

Cmake should probably support \\?\, right? Seems like this may be worth an issue on their end. Cc @vron if you may want to open one.

@tgross35 tgross35 merged commit 08af05c into rust-lang:master Dec 11, 2025
28 checks passed
@github-actions github-actions bot mentioned this pull request Dec 10, 2025
@ChrisDenton ChrisDenton deleted the abspath branch December 11, 2025 17:01
@ChrisDenton
Copy link
Member Author

Cmake should probably support \\?\, right?

I would hope so, yes! Though it's possible it's some dependency that's ultimately to blame.

ChrisDenton pushed a commit that referenced this pull request Dec 12, 2025
## 🤖 New release

* `cmake`: 0.1.54 -> 0.1.55 (✓ API compatible changes)

<details><summary><i><b>Changelog</b></i></summary><p>

<blockquote>

##
[0.1.55](v0.1.54...v0.1.55)
- 2025-12-11

### Other

- Remove the `\\?\` prefix from paths
([#259](#259))
- Add Visual Studio 2026 support
([#255](#255))
- Make sure that cmake generate build files in current dir
([#194](#194))
- Set the MSRV to 1.65 and test this in CI
- Canonicalize the build directory
- Use `eprintln` instead to print the command running next
([#191](#191))
</blockquote>


</p></details>

---
This PR was generated with
[release-plz](https://github.com/release-plz/release-plz/).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@kornelski
Copy link
Contributor

This breaks long paths and file path components that have different meaning under the DOS path parser.

You can't remove the verbatim prefix without checking whether the rest of the path is actually compatible. \\?\C:\ may not be usable as C:\ paths.

See what path validation is done in the dunce crate, or just use that crate.

@ChrisDenton
Copy link
Member Author

I am aware. The only cases that could practical fail here are:

  • A directory component ends in a single dot
  • The path ends in a dot or a space
  • The basename is equivalent to a device name (drive paths only)

However, these cases have always broken because we use the build_dir path to set the current directory, which doesn't support such paths. The absolute best we could do here is error with good diagnostics. But that's only helpful if the path made it this far without breaking something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Canonicalization of paths fails on windows

3 participants