Repository navigation
Windows long path issues with the exported depfile #1162
Description
Hi! I'm not sure if this is an issue from cbindgen or from make itself, but while using corrosion-rs with a CMake project, corrosion is capable of creating CMake targets to automatically generate C bindings using cbindgen. However the --depfile option used outputs Windows long paths, which generates errors when using the MinGW Makefiles as a generator.
Corrosion issue : corrosion-rs/corrosion#671
In short cbindgen generates this depfile:
\\?\C:\Users\Stovent\Dropbox\Dev\CeDImu-RendererWGPU\renderer-wgpu\header.hpp: \
\\?\C:\Users\Stovent\Dropbox\Dev\CeDImu-RendererWGPU\renderer-wgpu\cbindgen.toml \
\\?\C:\Users\Stovent\Dropbox\Dev\CeDImu-RendererWGPU\renderer-wgpu\src\ffi.rs \
\\?\C:\Users\Stovent\Dropbox\Dev\CeDImu-RendererWGPU\renderer-wgpu\src\lib.rs
Which is then used to create a compiler_depend.make:
# CMAKE generated file: DO NOT EDIT!
# Generated by "MinGW Makefiles" Generator, CMake Version 3.31
//?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/build/Release/renderer-wgpu/corrosion_generated/cbindgen/renderer_wgpu/include/RendererWGPU_ffi.hpp: //?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/renderer-wgpu/cbindgen.toml \
//?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/renderer-wgpu/src/ffi.rs \
//?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/renderer-wgpu/src/lib.rs
//?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/renderer-wgpu/cbindgen.toml:
//?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/renderer-wgpu/src/ffi.rs:
//?/C:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/renderer-wgpu/src/lib.rs:
Which is not accepted by the make program:
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/Stovent/Dropbox/Dev/CeDImu-RendererWGPU/build/Release --config Release --target CeDImu-GUI -j 12 --
[build] renderer-wgpu/CMakeFiles/_corrosion_cbindgen_renderer_wgpu_bindings_RendererWGPU_ffi_hpp.dir/compiler_depend.make:4: *** target pattern contains no '%'. Stop.
[build] mingw32-make[2]: *** [CMakeFiles\Makefile2:1223: renderer-wgpu/CMakeFiles/_corrosion_cbindgen_renderer_wgpu_bindings_RendererWGPU_ffi_hpp.dir/all] Error 2
[build] mingw32-make[2]: *** Waiting for unfinished jobs....
If this is a make limitation that cbindgen can't bypass, maybe a workaround would to only use long paths when the outputted files needs it, and use regular path by default.
Activity
emilio commentedon May 29, 2026
I mean changing the path syntax seems ok-ish, but it seems like it might be a mingw issue right? Do they just not understand those paths?
hiSandog commentedon Jun 29, 2026
The depfile case sounds like it needs a generator-specific path normalization decision. If MinGW Makefiles cannot consume
\\?\long paths, cbindgen could either emit ordinary Windows paths when writing Make-compatible depfiles, or provide an option to control long-path syntax in depfile output. A regression fixture with a long Windows path and a dependency containing spaces would make the behavior much easier to lock down.invarispsc commentedon Sep 29, 2026
This doesn't only affect MinGW Makefiles. It also affects the Ninja generator.
Sample error message:
Also all cbindgen tests in tests/tests.rs fail on Windows for me (doesn't matter if long path support enabled or not).
For example:
Edit: After a bit of digging:
The long path syntax is the expected result of std::fs::canonicalize.
So the tests on Windows need fixing in any case.
The change might be easy to implement, but I don't know if cbindgen should get an option to control the long path syntax output. That option wouldn't do anything on any other platform than windows (which would be ok with me).
Doesn't seem hard to do. If nobody else wants, I could draft something.