fix: Support opt-out of static linking via LIBZ_SYS_STATIC=0

[polarathene]

This change refactors the want_static logic to additionally support LIBZ_SYS_STATIC=0 as an explicit opt-out to the static feature when libz-sys is a transitive dependency and the build environment prefers to dynamic link libz instead.

I've inlined some rough commentary should it help grokking the helper method to maintainers (and any future contributors), with clear intent of supporting opt-out from the crate's static feature. This could probably do with some revision, along with user visible documentation of ENV precedence over the crate feature.

---

Future work

A follow-up PR may want to further refactor the following with consideration of LIBZ_SYS_STATIC explicitly forcing a linkage preference as opposed to convenience fallback/assumptions (the commentary was contributed some time ago and lacks further context/sources):

libz-sys/build.rs

Lines 25 to 31 in 80c597a

	// All android compilers should come with libz by default, so let's just use
	// the one already there. Likewise, Haiku and OpenHarmony always ship with libz,
	// so we can link to it even when cross-compiling.
	if target.contains("android") || target.contains("haiku") || target.ends_with("-ohos") {
	println!("cargo:rustc-link-lib=z");
	return;
	}

libz-sys/build.rs

Lines 39 to 42 in 80c597a

	if !want_static &&
	!target.contains("msvc") && // pkg-config just never works here
	!(host_and_target_contain("freebsd") ||
	host_and_target_contain("dragonfly"))

libz-sys/build.rs

Lines 76 to 86 in 80c597a

	// Situations where we build unconditionally.
	//
	// - MSVC basically never has zlib preinstalled
	// - MinGW picks up a bunch of weird paths we don't like
	// - Explicit opt-in via `want_static`
	if target.contains("msvc")
	|| target.contains("pc-windows-gnu")
	|| want_static
	{
	return build_zlib(&mut cfg, &target);
	}

libz-sys/build.rs

Lines 88 to 100 in 80c597a

	// If we've gotten this far we're probably a pretty standard platform.
	// Almost all platforms here ship libz by default, but some don't have
	// pkg-config files that we would find above.
	//
	// In any case test if zlib is actually installed and if so we link to it,
	// otherwise continue below to build things.
	if zlib_installed(&mut cfg) {
	println!("cargo:rustc-link-lib=z");
	return;
	}
	// For convenience fallback to building zlib if attempting to link zlib failed
	build_zlib(&mut cfg, &target)

Likewise a follow-up PR may want to consider dynamic link support for zlib-ng:

libz-sys/build.rs

Lines 16 to 23 in 80c597a

	let want_ng = cfg!(any(
	feature = "zlib-ng",
	feature = "zlib-ng-no-cmake-experimental-community-maintained"
	)) && !cfg!(feature = "stock-zlib");
	if want_ng && target != "wasm32-unknown-unknown" {
	return build_zlib_ng(&target, true);
	}

The zlib logic already enforces a build if want_static == true, otherwise runs a test to check if a system library is available to link, and if not falls back to building from source.

References

For anyone engaging on the topic/support, these might be of interest:

• Historical context
• Removal of enforced static linking for cross-compilation
• Cross-compilation example with pkg-config
• Conventions used by other sys crates
  • <CRATE>_NO_VENDOR=1 (git, openssl)
  • <CRATE>_USE_PKG_CONFIG=1 (ssh, zstd, sqlite)
  • <CRATE>_STATIC=0 (pcre2, libz)

[Byron]

Thanks so much, this is fantastic work!

Let's keep working in this direction, to become comfortable to make the changes this needs to evolve.

Something I'd be looking forward to is to document the current behaviour in such a way that the documentation can be kept in sync with future changes. Maybe adding docs can happen, in parts, once the respective parts of the build script are refactored, so it's an incremental process as well.
Maybe… the build-script could be mostly self-documenting as well, with detailed doc strings, and the lib.rs docs only documents the big picture so people can control their builds without having to study the source.

All just ideas, let's see what happens next :).