[DSP] Moving away from Rust
by Paweł Świątkowski
22 May 2017
I spend last few weeks trying to understand how to connect QML and Rust and slowly realizing some things I want are probably just impossible to do. This is mostly due to Rust’s safety features, more precisely variable lifetime which did not want to play along nicely with external GUI lib such as QML.
I was prepare to abandon the project in this form and maybe rewrite it in some different language in future, but nice fellows on
devspl Slack convince me to try a different approach. Following their advice (I think it was mostly krzaq), I decided to separate graphical frontend completely (probably to Python) and leave hard-core application login as it is in Rust. So yeah, title is a little clickbait-ish, but what can I do…
As a first step, I decided to move the logic to a separate crate, called
bletchley_lib. It couldn’t have been easier, actually. All I had to do was to generate a crate with
cargo new bletchley_lib, then move all the dependencies to its
Cargo.toml and fix some visibility issues. I my main app (which right now serves as a CLI application) I had to put this in
Now, to have everything in order, I created another one crate, called
bletchley_ffi. Its goal is to separate ugly glue code, which will be used by FFI-enabled front-end app, from the core logic. For a start, I only glued one function - called it
encrypt. It takes two strings: filename of key file and filename of the file to encrypt.
The resulting code in
bletchley_ffi/src/lib.rs looks like this:
A couple of things as a comment:
- First we have a bunch of imports required for making FFI-compatible output.
#[no_mangle]directive is necessary so Rust compiler does not change function names into its own internal names, like it usually does.
- Everything is pretty unsafe, so it has to be wrapped in
- I always return zero for simplicity now, since it’s either success or miserable failure with a complete crash.
To check if it works, I created a following Python script:
It’s nothing too complicated, but… it works! The only thing worth mentioning is that depending on operating system,
cargo build of a dylib-type crate generates
.dylib (Mac) or
.dll (Windows). Because of that, we need to have additional code to load a lib with a proper file name.
So, it looks like the project is kind of back on the track. In next few days I’ll try to finally put some windowed application which would use underlying Rust logic.