[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: graphics/jpeg Vs graphics/libjpeg-turbo
On Mon, Dec 13, 2010 at 01:22:46AM +1300, david.sainty%dtsp.co.nz@localhost
> graphics/libjpeg-turbo is a drop-in replacement for graphics/jpeg,
> with the difference that it is significantly faster (claiming 2-4x)
> than graphics/jpeg on Intel-like platforms through using MMX, SSE and
> SSE2 SIMD instructions.
> Because it's drop-in compatible, it conflicts with graphics/jpeg. You
> can currently use it by editing graphics/jpeg/buildlink3.mk to pull in
> graphics/libjpeg-turbo/buildlink3.mk instead, and everything just
> works. However, it really needs a more convenient solution -
> One typical solution is something like a mk/jpeg.mk file. I count at
> least 189 .include "../../graphics/jpeg/buildlink3.mk" lines that
> would need to be edited.
> Another solution is in packages like x11/libX11 which do support
> automatically pulling in the non-modular alternatives.
> A further solution might be to move graphics/jpeg into
> graphics/libjpeg, and use graphics/jpeg as a wrapper package that
> pulls in the preferred package. That'd save editing all the current
> users of the jpeg library. The "alternatives" system looks like it
> was going this route (but also seems to be a neglected project?)
> Anyone care to suggest which is the right way?
If it's a drop-in remplacement, I guess binary package users could install
libjpeg-turbo instead of libjpeg and have binaries still work, right ?
How will the pkg tools deal with that ? Can we express in binary package
that 2 different dependancies can be used for the same thing ?
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |