I desire the opposite of that: something built into rustc which does what bindgen does natively as part of a Cargo-based workflow
Conversation
There's something to be said for not having to deal with the hellish traditional C++ and Java build systems at all.
Rust, Kotlin and legacy Java / C++ code handled together by the same declarative build system without make, cmake, configure scripts, ant, gradle, etc. is nice.
2
1
I would say that a good >90% of the -sys crates in my personal stack are C bindings.
Granted most of the apps I work on are services.
1
2
Some examples of what I mean:
* android.googlesource.com/platform/exter
* android.googlesource.com/platform/exter
These are external C libraries, but it's all brought into the standard AOSP system and can be referred to and called from C, C++, Rust or Java with standard cross-compilation, debugging, etc.
1
1
So you end up building the C, C++, Rust, Java, Kotlin, etc. with the same incremental ninja builds without really thinking about it as separate projects. Can refer to dependencies in the other languages and it just fits together well. Unlike my experience at all elsewhere.
1
1
1
I think it's pretty nice just referring to a C module from a Rust project and calling functions from it with it built and linked together for you without dealing with the details since it generates the bindings for you as part of cross-compilation to the appropriate target.
1
Yes that sounds great except I want it as part of a cargo workflow with no external dependencies besides cargo and rustc
1
I don't think rustc and cargo intend to provide that though. I'm not familiar with bazelbuild.github.io/rules_rust/ but it's basically the same thing outside AOSP. cargo-raze converts Cargo to Bazel and then it fits into the overall Bazel system with other languages like C.
1
I want this
Quote Tweet
Replying to @bascule @rikarends and 2 others
D recently added an "ImportC" feature like this.
The implementation was only 4klocs, which is pretty cool:
github.com/dlang/dmd/pull
1
It feels like you have this when using Rust in AOSP because you never need to use bindgen. You depend on the library, call the C code and when you modify the C code, the ABI has changed for the Rust code built with it too. So rustc doesn't do it, but it feels like it's doing it.
Cargo could provide comparable UX but I think it just doesn't have the ambition / goal to provide this. You would get better error messages from rustc being aware of it, but I don't think it's essential. I can't really see it either happening though.
1
Per the D patch, it seems like it could be a 4 kloc-ish change to rustc.
It would require an expert on the C standard. Maybe could do it.
1
Show replies