build(cmake): guard libtiff's missing Deflate target

[zachlewis]

Description

Fixes configuration failures when OIIO finds a previously autobuilt static libtiff package whose exported TIFF::tiff target references Deflate::Deflate without importing or defining that target.

Before TIFF discovery, this adds a narrow compatibility guard that quietly loads libdeflate's config package and aliases its static or shared target as Deflate::Deflate when necessary.

Fixes #4439.

Root cause

libtiff links static TIFF builds against Deflate::Deflate, causing the installed TIFF::tiff target to export $<LINK_ONLY:Deflate::Deflate>.

However, libtiff's installed tiff-config.cmake loads that exported target without importing its dependencies. The corresponding upstream template still contains # TODO: import dependencies.

Upstream report: https://gitlab.com/libtiff/libtiff/-/work_items/871

OIIO encounters this during checked_find_package(TIFF). CMake's FindTIFF module first attempts libtiff's config package, which exposes the malformed export. This is not specific to CMake 4.3: I reproduced it with CMake 3.29.6 and 4.3.1. Issue #4439 likewise originally reported CMake 3.29+ on Linux and macOS rather than a Homebrew-specific failure.

Why fix this in OIIO?

The underlying package-export defect belongs in libtiff, but an upstream fix will not repair already-installed libtiff releases or OIIO dependency caches. OIIO also builds the affected static libtiff configuration itself.

This also breaks OIIO's ability to self-build (some) dependencies that [in]directly depend on libtiff or deflate. (Not for any dependencies for which we currently have self-building recipes so far; but this has blocked me in the past from submitting PRs for some of the more complex (sub)dependencies (libheif comes to mind; maybe jxl...? can't remember, it was more than a year ago when I last looked into this)

The guard is intentionally defensive:

• it runs only when Deflate::Deflate does not already exist;
• libdeflate is searched quietly in config mode;
• it does not make libdeflate a new required dependency;
• it does not change TIFF's config-mode or module-mode selection;
• it does not hide an actually missing library if a TIFF export requires one.

Testing

Tested on:

• macOS 26.3.1, Apple Silicon
• AppleClang 21.0.0
• Homebrew 6.0.9
• libtiff 4.7.1
• libdeflate 1.23
• CMake 4.3.1 and 3.29.6

Verification performed:

• reproduced the original generation failure before the change;
• fresh config-mode configure with CMake 4.3.1 against the defective static TIFF export;
• build completed successfully: 126/126 targets;
• module-mode configure with Homebrew libtiff and libdeflate discovery explicitly disabled;
• configure with CMake 3.29.6 against the same defective static TIFF export.

Steps taken to verify:

• Built the wheel twice with the same persistent SKBUILD_BUILD_DIR, IGNORE_HOMEBREWED_DEPS=1, and without forcing a local TIFF rebuild. The first build autobuilt static TIFF 4.7.1 and libdeflate 1.23; the second found the cached TIFF package and completed without the previous Deflate::Deflate error.

No robots worth speaking of were harmed in the making of this PR

Assisted-by: Codex / GPT-5

Codex was used to trace the CMake package-discovery chain, inspect the libtiff exports, reproduce the failure, prepare the compatibility guard, and run the verification described above.

[Copilot]

Pull request overview

This PR adds a CMake-side compatibility guard in OIIO’s dependency discovery to prevent configuration failures when a previously installed/static libtiff config exports TIFF::tiff with an unresolved link interface dependency on Deflate::Deflate (libtiff config-mode defect).

Changes:

• Before checked_find_package(TIFF), conditionally find_package(libdeflate CONFIG QUIET) if Deflate::Deflate does not already exist.
• Alias Deflate::Deflate to libdeflate::libdeflate_static or libdeflate::libdeflate_shared when available.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.