libjpeg vs. libjpeg-turbo

[René J.V. Bertin]

On Wednesday May 20 2015 12:11:08 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.

There are (probably) a number of huge ports that would have to be rebuilt, among the already huge number.

Supposing no one uses the new features from libjpeg, there are 2 (temporary) options that can be used during a grace period:
1- symlink libjpeg.9.dylib to libjpeg.8.dylib
2- rename/relabel libjpeg.8.dylib to libjpeg.9.dylib

The latter would make libjpeg and libjpeg-turbo/mozjpeg interchangeable, but the former would have the advantage that anything built against this fake libjpeg.9.dylib would in fact register libjpeg.8.dylib in its "rpath".

I know it's a hack, but I simply cannot condone an approach that would force anyone to accept the rebuilding consequences of doing things properly, depending myself on my ports for productivity.

As a related question: libjpeg-turbo depends on port:nasm, but I cannot get it NOT to insist on reinstalling nasm+universal, not even using a path:${prefix}/bin/nasm style dependency. How to get around that? Evidently there is no point in installing nasm +universal just to build something +universal ...

R.