This removes the need for the remaining C interfaces.
Building any rust library with openssl adds a bunch
of depends such as foreign types via ffi and pkgconfg.
You are also required to have a prebuilt openssl.
Cross building and keeping up to date should be easier
with a pure rust implementation.
This bumps rustls to 0.6.1 which bumps webpki-roots.
We need this because the current version of webpki 0.8.0
has been removed from crates.io.
I created the 0.6.x rustls for hyper 0.10 support.
In future we should upade to hyper 0.11 which is rusls 0.8.0+
The current Git master doesn't build with Rust 1.17 because the
version of Rustls used on master doesn't built with Rust 1.17.
* Update the base64 dependency to ensure the version with a buffer
overflow fix is used.
* Update hyper-rustls to one that uses a version of Rustls that builds
with Rust 1.17, and that uses *ring* 0.9+, to ensure there are no
problems with accidentally linking multiple versions of *ring*, to make
the build easier to set up (especially on Windows), and to keep things
working once *ring* 0.7.* gets yanked.
* Update the rust-openssl dependency while we're at it.
With Rust 1.15, proc macros have been stabilized. Therefore
custom build scripts are not required anymore.
This commit removes all the previous machinery and the
need for nightly.
The only link not working just yet is coveralls, which
apparently needs a login by the owner and minor configuration
to work (e.g. webhooks).
Also please note that the Cargo.toml has changed to fix the
documentation link. It would need a re-publish to fix it appears.
serde_macros is no longer maintained and will eventually
fail on nightly.
Also in a hopefully not-so-distant future, we will be able
to use macros 1.1 in stable, and thus get rid of the
complication required for the hybrid approach.
That way, google-apis-rs can compile once again.
If not done, yup-oauth ends up being compiled with
an older serde (the one of google-apis-rs, it seems), even
though its code was generated by a possibly newer serde.
Signed-off-by: Sebastian Thiel <sthiel@thoughtworks.com>
Versions were chosen to allow for maximum flexibility
for users of this library, even if this breaks at compile time
thanks to incompatibilities in dependencies.
Rather that, than cargo claiming that it cannot use
a certain version.
Of course, once everything is >= 1.0, one can change to
standard semver compatiblity.
