Compile less libtiff bits for wheels - #9970
Conversation
|
Could you provide a copy of the timeout log? |
|
@radarhere Sure: https://github.com/python-pillow/Pillow/actions/runs/34201463923/job/101981777441 are recent failing runs that show logs copying libtiff documentation HTML around. |
|
Btw, regarding those runs: 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... |
|
I generally delete previous versions when adding a new version, so that it should support the latest version of Pillow and 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 |
|
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. |
|
@radarhere Ah, sure. I didn't double-check the failure reasons (just did |
| --with-jpeg-lib-dir=$BUILD_PREFIX/lib | ||
| ) | ||
| if [[ -z "$IOS_SDK" ]]; then | ||
| # iOS links libtiff statically, but otherwise we need the dylib. |
There was a problem hiding this comment.
How did you come to the conclusion that iOS behaves differently?
2 participants
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.