Build Themis as a part of libthemis-sys

[ilammy]

Usually Rust crates prefer to simply work out-of-the box. Instead of the current approach of expecting a native Themis library to be installed in the system we should be more user-friendly. We should not require the user to do anything more than add a single line to their Cargo.toml and simply run cargo build.

• [x] Check if a suitable Themis is already available in the system. If so then just use it.
  • [x] Look for Themis library and headers in system environment.
  • [x] Verify the version of the library and ensure it's compatible with ours.
  • [x] Leverage pkg-config on Linux, brew on macOS. Developing on Windows is suffering, I guess.
  • [x] It would be nice to allow the user to explicitly specify the path to the library and headers in case of non-standard installaton.
  • [x] It would be nice to allow the user to override the default linkage if necessary (static/dynamic).
• [x] If Themis is not available then try building it from source and link to it statically.
  • [x] Don't be 'smart', just run make and let it figure out the details. Install to OUT_DIR.
  • [x] Right now fetch core Themis repo as a submodule. Later this won't be necessary when Rust binding becomes a part of the core repo.
  • [x] Make sure the user experience is the same as with the core library.
  • If there is no crypto backend then we should fail the build with some helpful error message.
  • It should probably be possible to customize build flags if necessary.
  • It should probably be possible to use a cross-compiler if necessary.
  • [x] Provide a way to suppress building Themis from source and always rely on the system version. This will be important for Debian packaging, for example.
  • [x] Check for BoringSSL's dependencies (CMake, Make/Ninja, Go, C compiler, libclang) and produce nicer warnings
• [x] Make linkage between themis and libthemis-sys crates configurable as well. This will also be important for Debian packaging. Look at sodiumoxide for an example.

Core Themis is licensened under Apache 2.0. This crate deliberately uses the same license in order to be compatible.

[ilammy]

After some research I have decided to follow the build model of openssl crate which seems to provide reasonable separation of concerns:

• themis — a high-level wrapper providing Rust API
• libthemis-sys — raw FFI bindings to Themis, links against some native library
• libthemis-src — utilities for building Themis from (vendors) source code

themis depends on libthemis-sys and builds its API upon the provided FFI. It does not care how exactly Themis API is made available to it.

libthemis-sys is tasked with locating a suitable installation of Themis and linking against it. If the system does not seem to have Themis available then libthemis-src crate may be used to build it as a static library which can then be linked by libthemis-sys.

This should be enough to implement the following linking strategies:

• System installation of Themis

  Themis is expected to be available and discoverable in the system via its standard package manager. The libraries are linked using system's default strategy. Applications using themis crate are expected to be managed by the same package manager.

  Use-case: I'm a Debian maintainer and want to ensure that the application I package uses the same libthemis as the rest of the system.

• Custom installation of Themis

  Cargo is instructed to link against a particular installation of Themis in a particular way. Location of the library and static/dynamic linkage is configurable, but someone (like yourself) needs to make sure that the correct library and its dependencies are available when running the application.

  Use-case: I'm a software developer, I'm know what I'm doing and want to have control over the dependencies which I build myself.

• Vendored copy of Themis

  We build you a Themis and link against it statically so it works out of the box anywhere. Unfortunately, you still have to provide upstream dependencies: a C compiler and {Boring,Open,Libre}SSL. But they are likely to be already installed somehow so this should not be a problem in practice.

  Use-case: I'm a kitten, I want to run examples from your README right now! Na-tive... li-bra-ries?.. What's that? Is it edible?