On May 24, 2015, at 8:52 PM, Lawrence Velázquez wrote: > On May 24, 2015, at 9:00 PM, Ryan Schmidt wrote: > >> On May 24, 2015, at 9:43 AM, René J.V. Bertin wrote: >> >>> 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.
...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. >>> 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. There are situations where it is helpful. I don't think the jpeg libraries qualify. >> 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. Right, and specifically because mozjpeg is designed to be slower, and because the libjpeg-turbo people say mozjpeg is therefore not suitable as a general purpose system jpeg library, maybe it would be right for us to prevent users from doing that. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
