libjpeg vs. libjpeg-turbo

[Ryan Schmidt]

On May 20, 2015, at 5:11 AM, Clemens Lang wrote:

> Yes, we would have to revbump all dependents of the jpeg port if we do
> this. Since it is unlikely that mozjpeg and libjpeg-turbo will ever
> implement the changes to become compatible with libjpeg.9.dylib there is
> no way to avoid the rebuild for this kind of switch.

I wondered why libjpeg-turbo would not incorporate libjpeg 9 features, and found this article explaining why:

http://libjpeg-turbo.org/About/Jpeg-9


On May 20, 2015, at 3:46 AM, Clemens Lang wrote:

> I would rather like to see us drop libjpeg completely and replace it with
> libjpeg-turbo. Does anybody object to this approach?

I was aware of the libjpeg-turbo port, but had not looked into it. I remember that libjpeg 6b existed for a very long time before libjpeg 7, 8 and 9 appeared in rather short succession. I did not know that libjpeg had undergone a change of stewardship at that time, and that the new developer's changes often involved new experimental features which were not generally welcomed by others who feel that libjpeg should be a reference implementation of a standard, not a testbed for experiments. I had indeed updated the jpeg port to versions 7, 8 and 9 not due to any particular need to do so, but simply because they were the newest versions available.

Based on the above article, and the referenced instances of how the current developer of libjpeg is interacting with the community, I'm open to replacing jpeg with libjpeg-turbo, with the option to use the mozjpeg fork of libjpeg-turbo instead. This would involve verifying that libjpeg-turbo works (or at least builds) correctly on PowerPC and Intel Macs running 10.4 and up. Then, assuming it does, identifying all ports that link with libjpeg; changing the dependency from port:jpeg to path:lib/libjpeg.dylib:libjpeg-turbo; increasing their revision; and marking jpeg as replaced_by libjpeg-turbo.

I count over 200 ports marked as depending on jpeg; there might be more that aren't marked. It would be good to verify that at least a good portion of those can compile with libjpeg-turbo before committing, though it sounds like it's already pretty well-tested in other distributions.