RE: [INTERNALS-WIN] FR: add libtiff to winlibs and php-sdk/deps

Hi Christoph,

> -----Original Message-----
> From: Christoph M. Becker [mailto:[email protected]]
> Sent: Wednesday, January 25, 2017 12:11 AM
> To: Anatol Belski <[email protected]>; [email protected]
> Subject: Re: [INTERNALS-WIN] FR: add libtiff to winlibs and php-sdk/deps
> 
> Hi Anatol!
> 
> On 24.01.2017 at 20:08, Anatol Belski wrote:
> 
> >> -----Original Message-----
> >> From: Christoph M. Becker [mailto:[email protected]]
> >> Sent: Tuesday, January 24, 2017 7:24 PM
> >> To: [email protected]
> >> Subject: [INTERNALS-WIN] FR: add libtiff to winlibs and php-sdk/deps
> >>
> >> So would it be possible to add libtiff to
> >> <https://github.com/winlibs>, and to make a binary distribution available as
> part of the php-sdk?
> >> Note that TIFF support is not planned for PHP's GD binding for
> >> now[5], but as soon as TIFF support has improved, that is likely to change.
> >>
> > That's the exact reason libtiff  is not in the core deps, as it's not used anywhere
> in the core, or would be picked up otherwise where it's not expected. Instead,
> it's provided for PECL and is picked up when some ext or it's dependency
> requires it. You can find the current builds here
> http://windows.php.net/downloads/pecl/deps/ .
> 
> Thanks!  I wasn't aware of the PECL deps, but after a quick check, the available
> libtiff seems to be fine to build libgd with TIFF support for Windows.  (Also there
> is fontconfig, what is more than I had hoped for. :))
> 
Nice :) Thanks for checking!

> BTW, is there some publicly available repo for the sources of pecl/deps?
> 
Some are in the winlibs repo, but most are not. The reason is the concern on the space limits for free repos provided by Github, as we already put some huge sources for the core in the winlibs org. The sources for PECL libs are taken from the respective public sources and in most case it's built as is or with a minimal change for lib names, etc. Usually also they're built just once for the given compiler, except asked by someone to upgrade.

> > For now AFAIR, it's only used as a dependency in some of the Gnome
> > libs. The latest ones also use libjpeg-turbo,
> 
> libgd is supposed to support the classic libjpeg as well as libjpeg-turbo, so the
> one in php-sdk/deps appears to be fine.  I don't know (yet) whether libjpeg-turbo
> would be an improvement, so at the moment I'm fine to stick with the classic
> libjpeg. :)
> 
Yeah, that's fine. I was doing libjpeg-turbo for the gnome libs, as it's now recommended for gnome in favor of classic libjpeg. The libs would collide in PHP otherwise, as we use the classic libjpeg in the core. Doesn't matter functionally, but otherwise what I've seen, is that libjpeg-turbo has a lot of ASM optimization. As it only implements a subset of the classic libjpeg, would probably have to be thoroughly checked, but otherwise it could outperform the classic one on x86 architectures.

Regards

Anatol