Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 12 additions & 18 deletions src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -17,24 +17,18 @@
//! backends, controlled through this crate's features:
//!
//! * `default`, or `rust_backend` - this implementation uses the `miniz_oxide`
//! crate which is a port of `miniz.c` (below) to Rust. This feature does not
//! require a C compiler and only requires Rust code.
//!
//! * `zlib-rs` - this implementation utilizes the `zlib-rs` crate, a pure rust rewrite of zlib.
//! This backend is faster than both `rust_backend` and `zlib`. However, we did not set it as the
//! default choice to prevent compatibility issues.
//!
//! * `zlib` - this feature will enable linking against the `libz` library, typically found on most
//! Linux systems by default. If the library isn't found to already be on the system it will be
//! compiled from source (this is a C library).
//!
//! There's various tradeoffs associated with each implementation, but in general you probably
//! won't have to tweak the defaults. The default choice is selected to avoid the need for a C
//! compiler at build time. `zlib-ng-compat` is useful if you're using zlib for compatibility but
//! want performance via zlib-ng's zlib-compat mode. `zlib` is useful if something else in your
//! dependencies links the original zlib so you cannot use zlib-ng-compat. The compression ratios
//! and performance of each of these feature should be roughly comparable, but you'll likely want
//! to run your own tests if you're curious about the performance.
//! crate which is a port of `miniz.c` to Rust. This feature does not
//! require a C compiler, and only uses safe Rust code.
//!
//! * `zlib-rs` - this implementation utilizes the `zlib-rs` crate, a Rust rewrite of zlib.
//! This backend is the fastest, at the cost of some `unsafe` Rust code.
//!
//! Several backends implemented in C are also available.
//! These are useful in the rare cases where you were already using a C implementation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't assume these cases are rare and turn this into a listing of facts about why the C implementation may be useful. Remove rare would already do it for me.

Further, I'd love it if there was a way to mention typical problem with using any backend. What comes to mind is duplicate symbols, and issue even Rust backends have today, maybe along with a hint at workarounds. The trigger for this paragraph was me thinking zlib-ng-compat was probably good for that, but I wasn't sure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the experiments I've run it seemed like zlib-rs did not result in duplicate symbol issues. So you should be able to use the zlib-rs backend without worrying about what other C zlib flavors may be present, and the whole "use C to avoid duplicate symbols" angle should no longer be a thing.

I am not 100% certain about that though, it's been a while. I'll double-check.

Bit-identical output and symbol conflicts are the only reasons to use C backends, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I cannot actually reproduce the linker errors due to conflicting symbols with my old setup.

@folkertdev do you know if zlib-rs would cause symbol conflicts if you try to link it into a binary that also links zlib?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would cause conflicts right now, but we've added trifectatechfoundation/zlib-rs#322 and will release a new version soon where there should not be any conflicts so long as export-symbols is disabled (which is the default)

//! and need the result of compression to be bit-identical.
//! See the crate's README for details on the available C backends.
//!
//! The `zlib-rs` backend typically outperforms all the C implementations.
//!
//! # Organization
//!
Expand Down