gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about OSX compatibility


From: Daniel Ferreira (theiostream)
Subject: Re: Questions about OSX compatibility
Date: Thu, 15 Jun 2017 13:13:27 -0300

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.

>> The third matter comes to Opal's CGImageSource/CGImageDestination
>> APIs. In Opal, it is part of OpalGraphics (thus under CoreGraphics'
>> headers). However, in OSX, these interfaces are part of a separate
>> framework called ImageIO. That said, I think it does not make sense to
>> keep them inside OpalGraphics, but aside from that I don't know how
>> you see the issue. Is it the case of moving them to another module; to
>> another "subproject" inside Opal (e.g. OpalImage or something); or not
>> move it from OpalGraphics at all and just change where we are
>> installing the headers?
>
>
> 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?

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

-- Daniel.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]