On Monday May 25 2015 05:07:37 Mihai Moldovan wrote:

>> ...I assumed it was also about performance. If we object to changes IJG is 
>> making to jpeg, we can also just stop updating jpeg past 9, or we can 
>> downgrade it to 8.

++

>For me, it also is. I'm dependent upon a fast JPEG decompressor for another
>application I'm part of upstream. I do not particularly care what the default
>JPEG port is in MacPorts as long as there is a choice for being able to switch
>to libjpeg-turbo (i.e., a path-based dependency), but I very much prefer

Exactly; even if you can actually show a significant benefit to libjpeg-turbo 
in your application that doesn't mean that benefit exists in enough ports 
across the board to warrant forcing all ports to be rebuilt against it. In that 
case there would just be the need for something like a port_select mechanism to 
let libjpeg.dylib point to the library of choice, and make the appropriate 
headers available. In turn, installed ports will continue to function after 
switching the selected jpeg library, even if port:jpeg continues to provide v9.

>libjpeg-turbo for speed and compatibility reasons (again, Linux distributions
>switched to libjpeg-turbo and a cross-platform application benefits from the
>same toolchain even on the other platforms.)

If we assume that libjpeg-turbo is indeed fully ABI compatible with libjpeg the 
cross-platform toolchain argument is moot.
As to Linux distros having switched:
- not all apparently; gwenview has a commit to allow it to build against 
libjpeg v9 that was done by someone @gentoo
- how long ago was that done? Also, Linux tends to address a much wider range 
of hardware (both in age and specs) than OS X does. It'd be understandable that 
they stick to their choice as long as it doesn't become a disadvantage compared 
to the existing alternatives.

Heh. That reminds me of an insight from Evolution Theory that fits my views on 
software updating perfectly: Darwin shouldn't have used the term "survival of 
the fittest", but "non-survival of the non-fittest" :)

R
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to