Re:Rust/WinRT Public Preview
by masklinn on Friday May 01, 2020 @09:34AM
(#23041814)
Seems sensible though, the build.rs solution would require every project using rust/winrt to have a build.rs and code to load & codegen the modules (probably copy/pasted), so it'd be a lot more work for users of rust/winrt, though I guess it'd be less magic.
[ Parent
| on HN ]
Re:Rust/WinRT Public Preview
by steveklabnik on Friday May 01, 2020 @10:05AM
(#23042076)
Oh yeah, I agree. I’m really interested to see if this approach would work better than build.rs for some other projects too.
Hit the max nesting depth, but to reply about why,
because winrt::import! is reading (arbitrary?) filesystem paths and there isn't an equivalent for build.rs emitting 'rerun-if-changed'.
So, neither cargo nor the compiler really know of the paths, and cannot accordingly rebuild the sources when they change.
Perhaps they can only change when a corresponding version cargo does know about changes, anyhow, bypassing the build/module system with a proc macro is probably not something to be done lightly.
Re:Rust/WinRT Public Preview
by steveklabnik on Friday May 01, 2020 @02:33PM
(#23045104)
Fun trick regarding the nesting depth, I believe that if you click on the comment permalink itself, it will still let you reply. Regardless, no worries :)
I was totally forgetting rerun-if-changed! This is indeed a barrier in the general case. I think that it doesn't affect this crate, but I am not 100% sure. Regardless, thank you!
Bah... This seems like exactly the kind of thing that makes dependency tracking, and sandboxing compilation harder.
Re:Rust/WinRT Public Preview
by steveklabnik on Friday May 01, 2020 @12:33PM
(#23043776)
Why? I'm not an expert here, but it seems basically the same to me.