*: use libz-sys instead of bundled one #419
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using the built-in cmake to build zlib, it changes the source tree as madler/zlib#162 describes. This leads to the failure during [generating the docs][1]. So let's switch to libz-sys instead, which uses its own custom script to build zlib, and leave source tree as it is. Switching to libz-sys can also reduce the package size as we can ignore more sub modules. It should improve compile time if libz-sys is also a dependency of other crates. The only shortcoming is that libz-sys may not be compatible with grpcio, but I believe the chance is quite small given it's such a small library. And giving it's such a small library, the benifits like compile time or package size described above may be too small to be observed. [1]: https://docs.rs/crate/grpcio/0.5.0-alpha.5/builds/196235. Signed-off-by: Jay Lee <[email protected]>
BusyJay
added a commit
to BusyJay/libz-sys
that referenced
this pull request
Dec 20, 2019
Common cmake script uses builtin `FindZLIB` module to find where zlib is installed. The cmake crate allows `register_dep` to hint cmake to search the right place. libz-sys puts the library under build directory, which is however not the place where cmake is going to search. So this PR corrects the behaivior by moving the built library to lib directory. Another option is to set the root directory to build instead, but the layout may not look good. It has been an issue for downstream projects like tikv/rust-rocksdb#303. and tikv/grpc-rs#419.
BusyJay
added a commit
to BusyJay/libz-sys
that referenced
this pull request
Dec 20, 2019
Common cmake script uses builtin `FindZLIB` module to find where zlib is installed. The cmake crate allows `register_dep` to hint cmake to search the right place. libz-sys puts the library under build directory, which is however not the place where cmake is going to search. So this PR corrects the behavior by moving the built library to lib directory. Another option is to set the root directory to build instead, but the layout may not look good. It has been an issue for downstream projects like tikv/rust-rocksdb#303. and tikv/grpc-rs#419.
This was referenced Dec 20, 2019
hicqu
reviewed
Dec 23, 2019
Signed-off-by: Jay Lee <[email protected]>
Signed-off-by: Jay Lee <[email protected]>
BusyJay
force-pushed
the
use-libz-sys
branch
from
8a27489 to
a627974
Compare
overvenus
approved these changes
Dec 25, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using the built-in cmake to build zlib, it changes the source tree
as madler/zlib#162 describes. This leads to the failure during
generating the docs. So let's switch to libz-sys instead, which
uses its own custom script to build zlib, and leave source tree as it
is. Switching to libz-sys can also reduce the package size as we can
ignore more sub modules. It should improve compile time if libz-sys is
also a dependency of other crates.
The only shortcoming is that libz-sys may not be compatible with
grpcio, but I believe the chance is quite small given it's such a small
library. And giving it's such a small library, the benifits like compile
time or package size described above may be too small to be observed.