Cargo VS windows-rs

Anybody knows when cargo-add will be distributed in stable cargo? Seems merged already.

In this case the libary is cargo

We might not need to reserve all typos. Soon cargo add will be in the stable release and we are hoping to have crates.io start suggesting it along with or in place of the Cargo.toml snippet. cargo-add could check for typos when you add a dependency. We could even check for registry squatting. If all else fails, we can check for security advisories when adding a crate.

There is no specific reason for a program that uses the XDG dirs on other unices to not use them on macOS, other than some idea that it's "alien".

You can have ~/.config/. Nothing in macOS prevents you from having it. And so, some programs do. The worst thing that happens is that, instead of having one directoy ~/.foo you now have one directory ~/.config/foo and nothing else in ~/.config. But as soon as you add the second thing that uses ~/.config, you now have two directories in there instead of a second dotdirectory in ~.

It's just that for a bunch of them the XDG path is only used if it exists - e.g. emacs predates the spec, so it uses ~/.emacs.d (and a few others) first.

Cargo doesn't use the XDG paths at all, apparently - https://github.com/rust-lang/cargo/issues/1734. However it also needs a directory for binaries (~/.cargo/bin) and ~/.local/bin isn't actually in the spec at the moment (https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14).

Can I suggest using rustup (https://rustup.rs/) to manage the rust tool chain and cargo (installed by rustup, but https://github.com/rust-lang/cargo) to manage builds and packages? It makes it much easier to handle projects especially with dependencies. The book (https://doc.rust-lang.org/stable/book/title-page.html) outlines how to use it and some stuff for advancing with rust

The package in question was updated to v3.0 three weeks ago, at the same time as heron itself. Even when I explicitly define the dependency pointing at the git repo (which should find the package subdirectory):

I believe this is the relevant tracking issue

Use Cargo.toml instead of package.json. You’ll want to add them manually (instead of using a command like yarn add)

Windows might be possible to construe as "Pure Rust" even under this definition, as the windows crate is Microsoft's direct projection of the Windows API into Rust, with no C headers involved. (In fact, the ABI is even extern "system", not extern "C", so you can pretend it's less C.)

I would recommend to use the official rust projection of the windows api from Microsoft. I had a very good experience using it and you can mostly reference the official Microsoft api documentation for C++ if the Rust docs are lacking in some regard.

In any case, maybe you want to have a look at this, https://github.com/microsoft/windows-rs/tree/master/crates/samples/direct3d12

Project is written in Rust and rust bindings to Windows API - https://github.com/microsoft/windows-rs

I know Microsoft is putting effort into providing documentation and API bindings for using Rust on Windows and have used it for a component or two, though what beside one of their Azure components is unclear.

Nope, I was speaking about this,

https://github.com/microsoft/windows-rs/tree/23ff38bbbf46fb5...

Apparently since last November they decided to replace it with another approach, so my information is outdated.

Nope, they are shipping binaries.

https://github.com/microsoft/windows-rs/tree/master/crates/t...

Microsoft is getting behind Rust with things like this guide and these API bindings.

Microsoft created a language agnostic metadata project for the Windows api to auto-generate language bindings for it. The language bindings for Rust are generated with it for example. One big advantage with them is, that instead of a #define, the types such as HANDLE, etc. are indeed real types wrapping a void* (or a int, or whatever). So it's much harder to pass the wrong type and IDEs give much more helpful type information.