Re: Questions about OSX compatibility

[Sebastian Reitenbach]

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

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.

just my 2 cents.
Sebastian

>
> >
> >> (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.
>
> ¯\_(ツ)_/¯
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev