This PR is similar to #50, but determining to use / vs \ based on the host OS, not the target OS.
From Maximum Path Length Limitation: File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections. If the OUT_DIR directory for the current build on a Windows host is prefixed with "\\?\", then include!(concat!(…, "/…")) does not work:
couldn't read \\?\D:\a\tokio\tokio\target\debug\build\rustversion-2d44b26e828f2c8d\out/version.expr: The filename, directory name, or volume label syntax is incorrect. (os error 123)
Specifically for a procedural macro crate, using target_os like in #50 sort of works, but only because Cargo does not support cross-compiling procedural macro crates (it just ignores --target if --package refers to a macro). But other build systems definitely support cross-compiling proc macros, and would be broken by #50 if target_os is Windows but the host is not.
This PR is similar to #50, but determining to use
/vs\based on the host OS, not the target OS.From Maximum Path Length Limitation: File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections. If the OUT_DIR directory for the current build on a Windows host is prefixed with "\\?\", then
include!(concat!(…, "/…"))does not work:Rustc or cargo do not have any built-in way to handle including code from OUT_DIR robustly (https://github.com/rust-lang/rust/issues/75075).
Specifically for a procedural macro crate, using
target_oslike in #50 sort of works, but only because Cargo does not support cross-compiling procedural macro crates (it just ignores--targetif--packagerefers to a macro). But other build systems definitely support cross-compiling proc macros, and would be broken by #50 iftarget_osis Windows but the host is not.Closes #50.