libjpeg vs. libjpeg-turbo

Lawrence Velázquez larryv at macports.org
Sun May 24 18:52:31 PDT 2015


On May 24, 2015, at 9:00 PM, Ryan Schmidt <ryandesign at macports.org> wrote:

> On May 24, 2015, at 9:43 AM, René J.V. Bertin wrote:
> 
>> I think I made it clear that I have this requirement, but I suppose I'll just keep extending my own port repository.
> 
> No, sorry, I missed that you have this requirement. Why do you need libjpeg instead of libjpeg-turbo?

I'm not convinced that it's "need" so much as "want".

>> but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise.
> 
> ...which exercise?

Replacing libjpeg with libjpeg-turbo. I think this point is off-topic, as this discussion is primarily about maintainability and not performance.

>> The issue is moot if port:jpeg is discontinued. If it's not, it's special in that there are 3 alternatives that each provide one of two ABI versions, and only port:jpeg being unambiguous about what version it provides.
>> Anyway, I think it's something that can be decided upon on a case-by-case basis. There is precedence; gstreamer comes to mind.
> 
> gstreamer1 and gstreamer010 are named after the project version number, not any included library's version number. There are many many ports named after the project version number

Yes, and nearly all of them are a significant pain to maintain. This is one reason I'm paring back our Python selection. (GCC is on deck.) I would like to avoid creating more versioning if we can help it.

> But if we don't let the user choose between libjpeg-turbo and mozjpeg, how then is a user who wants to use mozjpeg going to do that? Imagine I want to compress a bunch of images using ImageMagick, and I want them to be as small as possible, and I don't care if it takes longer to encode them. That's what mozjpeg is for. I had envisioned that in this situation, I would force-deactivate libjpeg-turbo, activate mozjpeg, and then use ImageMagick as planned. Then when I was done I would deactivate mozjpeg and re-activate libjpeg-turbo. Though thinking about it now, I guess for that use case it wouldn't really matter if ImageMagick declared its dependency on path:lib/libjpeg.dylib:libjpeg-turbo or just port:libjpeg-turbo; either way, libjpeg-turbo will have to be forcibly deactivated.


It doesn't matter for that specific case, but a user who for some reason wanted to always use mozjpeg could still install it up front and let all dependencies pick it up.

vq


More information about the macports-users mailing list