Re: Questions about OSX compatibility

[Ivan Vučica]

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:
>> My view is a new 'project' (repository) per framework would be good enough.
>> It would certainly be clear what you need to clone in order to get
>> 'ApplicationServices/ApplicationServices.h' if the repository was called
>> 'libs-applicationservices'. Using git submodules, we can also ensure
>> dependencies are installed at the same time.
>
> Hm, why not keep ApplicationServices, for instance, as a
> submodule-only repository with the global header pointing to all of
> them and some script/makefile which installs everything inside it?
>
> If properly versioned (and *this* is an overhead, unfortunately), it
> wouldn't conflict with the submodules themselves being installed
> separately.
>
> But this seems to reflect how things are in fact, with
> ApplicationServices doing nothing really and just grouping other
> frameworks.

That sounds like what I meant above? Use submodules to deploy other
dependencies in subdirs, and then use SUBDIR variable in GNUmakefiles
to get make to build the other frameworks, too?

Note that I keep forgetting that .gitsubmodules always refer to a
specific commit, not to a branch. So we don't really want submodules,
I think.

>> 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?

>
>> (Which reminds me... I should really rename 'quartzcore' project into
>> 'opalanimation' or something like that.)
>
> Why is 'quartzcore' not part of Opal, by the way?

Original committer who deployed the stub headers (see history of the
repo) presumably chose how to approach it.

That said, there isn't really much need to.

Core Animation /is/ a very distinct thing from Core Graphics, and if
you could adjust the API, you could comfortably substitute uses of
CGContextRef with something else (SDLSurface, e.g.) /without/ the API
becoming /very/ different. There isn't much that Core Graphics
(quartz2d, opalgraphics) and Core Animation (which happens to ship in
QuartzCore on OS X) have in common besides CALayers being fed
graphical content from CGContextRefs (or supplying CGContextRefs for
someone else to draw into).

Core Animation deals with rendering (potentially) 3D layers of content
and properties, animated using certain animation functions, and being
spit on the screen through OpenGL (or similar 3D graphics API).

Core Graphics deals with rasterizing 2D content into 2D bitmaps.

¯\_(ツ)_/¯