Compile less libtiff bits for wheels

[akx]

I noticed a timeout-failing build log for wheels copying HTML docs into place, which sounds quite unnecessary, so I took a critical look at the libtiff build flags.

libtiff contrib, C++, dependency tracking, docs, tests, tool binaries are no longer built with this, and for non-iOS builds, statically linked files neither.

[radarhere]

Could you provide a copy of the timeout log?

[akx]

@radarhere Sure:

https://github.com/python-pillow/Pillow/actions/runs/34201463923/job/101981777441
https://github.com/python-pillow/Pillow/actions/runs/34201463923/job/101981777487
https://github.com/python-pillow/Pillow/actions/runs/34201463923/job/101981777533

are recent failing runs that show logs copying libtiff documentation HTML around.

[akx]

Btw, regarding those runs:

  Download pillow dependency sources...
  100  297M  100  297M    0     0  26.4M      0  0:00:11  0:00:11 --:--:-- 23.4M

Does https://github.com/python-pillow/pillow-depends/archive/main.zip need to have 297 megs of stuff? I noticed the history of https://github.com/python-pillow/pillow-depends had reverted deletion of some old versions at some point...

[radarhere]

I generally delete previous versions when adding a new version, so that it should support the latest version of Pillow and main. I've just cleaned it up now.

I'm not sure which commit you're talking about when you say deletion had been reverted. If it is python-pillow/pillow-depends@08e2235, then see #8603

[radarhere]

I know you may not have meant this, but to be clear, only one of the logs you linked to shows a failure from a timeout. The other two are legitimate errors.

[akx]

@radarhere Ah, sure. I didn't double-check the failure reasons (just did uv run gha-stats grep html-prebuilt/tools/tiffinfo.html python-pillow/Pillow | grep -v success | grep -oE https://.+ (gha-stats being a little tool I built for figuring out what parts of GHA runs take longer, etc.))

[radarhere]

How did you come to the conclusion that iOS behaves differently?

[akx]

2af930b's comments:

# A safety catch for iOS. iOS can't use dynamic libraries, but clang will prefer
# to link dynamic libraries to static libraries. The only way to reliably
# prevent this is to not have dynamic libraries available in the first place.
# The build process *shouldn't* generate any dylibs... but just in case, purge
# any dylibs that *have* been installed into the build prefix directory.

[radarhere]

These changes are fine.

Looking again at those logs, I don't think I see any libtiff timeout in them. But you view this as primarily a performance PR, yes? I wonder at what point extra complexity outweighs minor performance gains.

The AVIF build is also complex, but that was trying to significantly reduce wheel sizes.

[akx]

I don't think I see any libtiff timeout in them.

No, it's not a libtiff build specific timeout. I just saw a failed build and figured we could make things faster and leaner in general by not building the extras we don't need.
The Wheels job takes 1 to 2 hours of compute time every time - while Pillow doesn't pay for it monetarily, I don't see a great reason to spend cycles doing nothing and "burn up" concurrency limits if the alternative is a couple lines of sharper configuration like this PR.