[tiff] Fix find_package in cmake wrapper

[dg0yt]

• What does your PR fix?

  • Instead of unconditionally using REQUIRED when finding feature dependencies of tiff, properly respect the options given to find_package(TIFF).
    Requires at least CMake 3.3 for project mode (as do some other wrappers).
    Follow-up from [meson] Update meson to 0.58.1  #18393 (comment) - CC @Neumann-A
  • Replace the feature name pattern matching by proper if ("name" IN_LIST FEATURES) if(@<feature_var@>).

• Which triplets are supported/not supported? Have you updated the CI baseline?

  all / no.

• Does your PR follow the maintainer guide?

  yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  yes

[dg0yt]

I will update this PR to set CMP0057 to NEW, for using IN_LIST.

[ras0219-msft]

I don't think this is the right solution, because it results in very strange behavior:
simage[jpeg] -> uses jpeg dependency
simage[tiff,jpeg] -> uses tiff & jpeg dependency
simage[tiff] -> fails to find tiff because jpeg is blocked (!)

Instead, I think the right approach is to unset CMAKE_DISABLE_FIND_PACKAGE_XYZ when in a cmake_wrapper searching for a transitive dependency. This does potentially result in bad behavior where simage[tiff] -> uses tiff & jpeg dependency, but I think this is still a better outcome (and it's still deterministic & correct w.r.t. binary caching).

[ras0219-msft]

More generally, I think we need to move to a different mechanism than CMAKE_DISABLE_FIND_PACKAGE_XYZ (related: #15808), since the semantic we're trying to express in the portfile is really not quite the disable macro. We're generally trying to say "This build should not directly find this optional dependency, since it has not enabled the feature macro", not "This build should never (even transitively) depend upon package X". Maybe that means we need a "VCPKG_DISABLE_PACKAGE_XYZ" macro instead that captures this "one-level-deep" semantic which we could implement quite easily in our find_package replacement.

[dg0yt]

simage[tiff] -> fails to find tiff because jpeg is blocked (!)

Yes.

Instead, I think the right approach is to unset CMAKE_DISABLE_FIND_PACKAGE_XYZ when in a cmake_wrapper searching for a transitive dependency. This does potentially result in bad behavior where simage[tiff] -> uses tiff & jpeg dependency, but I think this is still a better outcome (and it's still deterministic & correct w.r.t. binary caching).

Without this PR, simage[tiff] wouldn't build at all. One might argue that this is also a valid and desired outcome:

• CMAKE_DISABLE_FIND_PACKAGE_XYZ is a tool to control dependencies.
• Features are to be enabled by explicit options instead.

From that POV, simage[tiff] must opt out of tiff's jpeg feature.

---

PS I see @ras0219-msft just posted another comment which seems to support this POV.

[Neumann-A]

Uppdate simage to 1.8.1 ? They changed all find_package call to REQUIRED and have variables called SIMAGE_USE_XY

[JackBoosY]

@dg0yt So I suggest you to update simage to 1.8.1 first.

[dg0yt]

@dg0yt So I suggest you to update simage to 1.8.1 first.

@JackBoosY I'm not going to start with simage. I don't use it. I don't test with windows triplets outside CI. It is not clear to me what is the desired state for image format support:

• Image format libraries are explicitly disabled for osx and windows (but not for uwp 💣 )
• Image format dependencies explicitly exclude osx and windows (including uwp 💥 - cf. [simage] Fix optional dependencies #15683 (comment)).
• I have no idea why image formats are disabled at all for a port like simage on windows and osx.

[dg0yt]

This work is complete. However, there should be public guidelines for cmake wrappers. And there is #18631.

[PhoebeHui]

PR #18645 upgrades the simage to 1.8.1.

[dg0yt]

PR #18645 upgrades the simage to 1.8.1.

The changes in this PR (#18473) are unrelated to simage (even if simage was the trigger).

[JackBoosY]

Ping @ras0219 @ras0219-msft for respose.

[JackBoosY]

Ping @ras0219-msft for review this again.

[dg0yt]

@ras0219-msft In the light of writing down best practices for wrappers, there are two issues I want to point out.

• The replacement of if(@<feature>@) is an unquoted if(ON).
  I wonder if it would be better to use a quoted if("ON") even if its unlikely that someone creates variables named ON or OFF.
  It also needs CMP0012 which is not automatically active for some consuming projects.
• Properly dealing with the transitive dependencies is cumbersome. We don't have access to the Package File Interface Variables, and even ARGS may get lost before calling _find_package when looking up dependencies first (going through the find_package macro which has a limited backup capability).

[github-actions]

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated

git add -u && git commit
git checkout 6b24f0fa76d171c5756f01f407682f7274cfe238 -- versions
./vcpkg x-add-version --all

Diff

diff --git a/versions/t-/tiff.json b/versions/t-/tiff.json
index 5c84ed3..29367b7 100644
--- a/versions/t-/tiff.json
+++ b/versions/t-/tiff.json
@@ -1,7 +1,7 @@
 {
   "versions": [
     {
-      "git-tree": "aab7feb7ca21fc2343fff20bf27d92a95d0b5e69",
+      "git-tree": "f147253c84ad1d911393d8b5496f30574a07c780",
       "version": "4.3.0",
       "port-version": 2
     },

[dg0yt]

Ping for review.

[JackBoosY]

I think I can accept this.

[BillyONeal]

This makes sense to me but I want @ras0219 / @ras0219-msft to OK it.

[ras0219-msft]

I think this is a solid improvement, though it can't fully resolve the issue until we implement some non-transitive blocking capabilities for find_package.