Opened 11 years ago
Closed 10 years ago
#43618 closed update (wontfix)
ipe update to 7.1.5
| Reported by: | m.thon@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | maintainer haspatch | Cc: | kurthindenburg (Kurt Hindenburg) |
| Port: | ipe |
Description
version update to ipe-7.1.5
New:
1) ipe now uses the turbo-jpeg API to read jpeg files. AFAIK this is problematic in MacPorts, since the jpeg and libjpeg-turbo ports conflict, and there is no way to install both. I therefore add a patch to replace the relevant code with the standard jpeg API. Also, I set the jpeg dependency as
path:lib/libjpeg.dylib:jpeg
as mentioned in #38907. Hope this is the best way to go.
2) I added a variant to compile the optional "qvoronoi ipelet", since this is now part of the default Windows binary. This currently needs a minor patch to compile with clang.
3) I also used the opportunity to update my maintainer e-mail address.
Attachments (3)
Change History (9)
Changed 11 years ago by m.thon@…
| Attachment: | Portfile-ipe.diff added |
|---|
Changed 11 years ago by m.thon@…
| Attachment: | patch-ipelets-qvoronoi-qvoronoi.cpp.diff added |
|---|
Changed 11 years ago by m.thon@…
| Attachment: | patch-ipelib-ipebitmap.cpp.diff added |
|---|
comment:1 follow-up: 2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 11 years ago by m.thon@…
Replying to ryandesign@…:
... you could install libjpeg-turbo instead of jpeg and all software that uses jpeg would work correctly.
I don't really know either libraries well. But I think that is basically true. However, it does not go the other way round: libjpeg-turbo provides an additional more convenient API, i.e., libjpeg-turbo supports the standard libjpeg API and its own API. Ipe now makes use of the libjpeg-turbo API, so unpatched it requires libjpeg-turbo and not libjpeg. With the patch it can use either.
Unfortunately, several ports (including ipe dependencies) seem to require jpeg. At least I couldn't figure out how to replace jpeg by libjpeg-turbo in my MacPorts.
comment:4 Changed 10 years ago by kurthindenburg (Kurt Hindenburg)
If you're interested in updating this to 7.1.7, I'll commit it for you.
comment:5 Changed 10 years ago by m.thon@…
Hi, I now updated this to 7.1.7 and put it in a new ticket #47280, which makes this ticket obsolete.
It would be kind if this ticket could be closed and the new ticket committed.
comment:6 Changed 10 years ago by mf2k (Frank Schima)
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
| Version: | 2.2.1 |
The reason why jpeg and libjpeg-turbo conflict with each other and install files to the same locations is that I was under the impression that libjpeg-turbo was a drop-in replacement for jpeg. In other words, you could install libjpeg-turbo instead of jpeg and all software that uses jpeg would work correctly. But now you're saying libjpeg-turbo has a separate and different API that is not compatible with jpeg?