Re: Questions about OSX compatibility

[Fred Kiefer]

Am 16.06.2017 um 08:29 schrieb Sebastian Reitenbach <address@hidden>:
>> On Thursday, June 15, 2017 21:28 CEST, Ivan Vučica <address@hidden> wrote: 
>> On Thu, Jun 15, 2017 at 5:13 PM, Daniel Ferreira (theiostream)
>> <address@hidden> wrote:
>>> On Thu, Jun 15, 2017 at 9:09 AM, Ivan Vučica <address@hidden> wrote:
>>>> This one, I'd keep it in the Opal repo.
>>>> 
>>>> """Originally part of the Core Graphics framework, Image I/O resides in its
>>>> own framework to allow developers to use it independently of Core
>>>> Graphics."""
>>>> 
>>>> OpalImage sounds like a nice name.
>>> 
>>> There's an issue with compatibility though. If existing binaries link
>>> dynamically to OpalGraphics expecting the ImageIO symbols in there, we
>>> cause them to break, for instance. How would you suggest we make this
>>> change to OpalImage without these consequences?
>> 
>> True, that's indeed a concern for distros.
>> 
>> I was going to suggest that we don't care and simply have people
>> rebuild their software, but we would be breaking binary compatibility,
>> which would make distros demand blood from us.
>> 
>> How about OpalGraphics's implementations of the functions
>> 1) print out a warning
>> 2) dlopen() ImageIO and execute the symbols there?
> 
> at least as an OpenBSD packager, I'd say "no issue", 
> but more seriously: Why not just do a major bump of the
> library and done. Everyone knows such major bumps
> may break existing things. Release notes should provide
> a clear way forward for people/packagers/distris.

As far as I know there are no applications out there using opal. Up to now this 
library is work in progress. A year ago I fixed some substantial issues in it, 
which nobody had complaint about.
Still I don't see a reason for splitting this up. What we need is some header 
files with the expected includes for the existing headers. For linking we will 
need to provide our own build scripts anyway.
We don't need to provide stuff in the exact same form as Apple does.

Having the files in a subdirectory of opal called OpalImage seems like a good 
idea though.

Fred