How to distribute the closed-source compiled rlib files? Is there the corresponding documentation?
As far as I understand, I have to add the build script. But when trying to do this, I receive messages like this
error[E0460]: found possibly newer version of crate `other_s_crate` which `my_crate` depends on
Here it is assumed that the license terms are fully satisfied in the crates that I'm going to use. Moreover, there are very high chances that my crates and the user's code will use the same other's crates.
It would be fine to have something similar to C/C++ object files that could be distributed for each specific version of the compiler and platform with all the implications that follow from this. Providing the C API is not an option.
To further explore that path you should have a look at ::abi_stable which provides FFI that does not require going through C APIs/ABI.
Personal remark about rlib and closed source
rlib might be easier to set up, but I wouldn't trust an rlib being hard to reverse engineer, as they contain, for instance, plenty of metadata to allow monomorphisation of generic functions (in a maybe similar situation, .pyc files, for instance, can be perfectly reversed back to the original .py, with docstrings included and all (but not comments obviously)).
Note that I don't know the exact internals of rlibs, so I might very well be wrong; but I prefer to err on the side of caution, and wait for somebody to contradict me if that's the case
The rlib metadata contains spans for all definitions, it contains mir for all #[inline] and generic functions and it contains all type and macro definitions.
You should also be aware that rust doesnt have a stable abi, so every new version of rustc requires you to compile again.
Currently supported version is to export a C API, compile as cdylib, not rlib, and treat the resulting library like any other C library. You can then create an open-source Rust wrapper for the C-ABI library to get a nice interface back.
Thanks for the reply! Unfortunately, all the code is about high speed of computations, where I have to create objects primarily on the stack and combine computations with help of inlinable lambda functions. So, providing the analogous C API would degrade essentially the performance.
The generic and inlineable parts can't really be closed-source, because the compiler needs to be able to recompile and optimize them with the new types/lambdas. It's a similar problem to having to put C++ templates in header files.
I don't think there's a way around that. For example, Swift has a stable ABI for generics, but it doesn't support monomorphisation in that case. Generic Swift ABIs are compiled to a form similar to using Box<dyn Trait> for absolutely everything, even sizeof().
Still, if you split it in two — closed part behind a C ABI, and open part with a Rust API, you can try moving generic and inlineable parts to the open side.
If it's so generic that it can't be done, then you may need to distribute the source and rely on legal means to keep it secret.
I realized your idea. I thought of the same, but I'm unsure whether it is feasable.
Yes of course, in case of C++ some parts will be defined with help of templates, which must be distributed in the header files. I would also be glad to distribute the Rust rlib files that contains much metadata, but I don't know how to handle the common dependencies.
