On Thursday, June 15, 2017 21:28 CEST, Ivan Vučica <i...@vucica.net> wrote: > On Thu, Jun 15, 2017 at 5:13 PM, Daniel Ferreira (theiostream) > <bnm...@gmail.com> wrote: > > On Thu, Jun 15, 2017 at 9:09 AM, Ivan Vučica <i...@vucica.net> 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 > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev