On May 24, 2015, at 9:00 PM, Ryan Schmidt <[email protected]> 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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
