Questions about OSX compatibility

[Daniel Ferreira (theiostream)]

Hi guys,

Over the last days I've moved on with compiling WebKit based on
GNUstep, and some recent issues over how to move some headers around
for OSX compatibility. I'll mention many loosely related issues since
they overlap at some point.

The first issue is that of framework amalgamation. Apple has
frameworks like ApplicationServices.framework[1] or
CoreServices.framework that don't do much by themselves. However, have
"sub-frameworks" both in their headers. For instance,
ApplicationServices.h includes CoreGraphics, CoreText, ImageIO,
HIServices and many others. Supposing GS implemented all of these
frameworks, how should we handle the installation of this "global
header" that imports all of these frameworks given the current module
model?

The second matter comes to CarbonCore's Unicode and text conversion
facilities (e.g. TEC* functions[2]). They have not yet been deprecated
by Apple and are used by WebKit, and would thus need to be implemented
in GS. Ivan suggested there might be a case for expanding
https://github.com/gnustep/libs-ucsdata's purpose into including these
functions. Do you agree with this or should it become part of another
framework or be a new one?

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?

Thanks,
-- Daniel.

[1]: https://developer.apple.com/documentation/applicationservices#overview
[2]: 
https://developer.apple.com/documentation/coreservices/1571815-teccreateconverter?language=objc