Rust bindings lack flexibility with current structure of build script

[ralexstokes]

I'm using a niche devops flow with nixos and I've found the current structure of the Rust bindings in this repo are problematic. As far as I can tell, this has to do with the placement of the build.rs in a subdirectory with respect to the C code. I expect there were similar issues with other language toolchains given the placement of the Go and Nim files at the repo root.

I can point to these resources that helped me diagnose the issue:

ipetkov/crane#473 (comment)
ipetkov/crane#271 (comment)

And in particular (regardless of nixos), you'll find that trying to build the bindings locally using cargo vendor fails.

I haven't tried it yet, but I suspect we should just place the Cargo.toml and build.rs as the project root. If we are open to modifying the repo to get cargo vendor to succeed then I'm happy to make a PR to diagnose further.

There seems to be a quirk of crates.io that pulls the entire repo so that something like this works for my use case, but I would prefer we pursue a successful cargo vendor as that should solve the problem instead of having to maintain a fork of all the consumers of this project.

[jtraglia]

If we are open to modifying the repo to get cargo vendor to succeed then I'm happy to make a PR to diagnose further.

Hey @ralexstokes! This is an interesting problem. I'm open to changing things. But I would like to hear about this from other Rust people before suggesting we do anything. @pawanjay176 @asn-d6, thoughts?

[asn-d6]

Hmm, it feels dirty to dump Cargo.toml and build.rs to the project root, but it seems like we already have golang and nim-related files there. So dirtiness is already there, and hence I wouldn't oppose this change.

I wonder if it's possible to do something using cargo workspaces. From reading a bit about it, even if it's possible, we would still need a Cargo.toml in the project root to specify the location of the rust bindings.

The extreme (not proposed) alternative is to move all bindings to their own git repo so that they can freely manage their directories.

[akorchyn]

+1 to this issue. I'm using nixos for my DevOps too and it fails to work:(
This is because of strict rules for what application can access, and it fails to vendor the crate.