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.

[lgritz]

Internally, we use checked_find_package, which has lots of bells and whistles, including that it will be included in the build log report of which dependencies were found at which version.

[zachlewis]

There's something about when + how checked_find_package does what it does that makes it difficult for the config that libtiff sets up that fails to survive a rebuild, when the locally-built libtiff is rediscovered... I don't really understand enough about what's happening behind the scenes to grok exactly what's going on. But the only thing that seems to work is forcing tiff to always build locally (when rebuilding using an existing build dir persisting previously built deps).