CPP, Leopard and Haskell Objective-C bindings
It seems that the current approach taken by HOC is to strip preprocessing directives. This may not have been a problem before Leopard but Cocoa header files are now full of macros in most unusual places, e.g. @interface NSObject (NSDeprecatedMethods) + (void)poseAsClass:(Class)aClass DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER; @end I'm trying to figure out the easiest way to run CPP over the header files before processing them in HOC. Is there a CPP written in Haskell and packaged as a library? Does someone have a quick Haskell solution for running CPP over a header file (with include paths?), redirecting into a temp file and reading that back into Haskell? Should I preprocess all Cocoa header files using make and then read these in? Thanks, Joel -- http://wagerlabs.com
Is there a CPP written in Haskell and packaged as a library?
Yes, cpphs, which can be used either as a stand-alone tool or as a library. http://haskell.org/cpphs Regards, Malcolm
On 6-Nov-07, at 5:00 PM, Joel Reymont wrote:
It seems that the current approach taken by HOC is to strip preprocessing directives.
True. Additionally, some of those strange macros are just interpreted as language keywords by the parser.
I'm trying to figure out the easiest way to run CPP over the header files before processing them in HOC.
That is not exactly what we want, I think. Currently, HOC parses things file-by-file, so we do NOT want to follow #include directives. We might just process the line pragmas from CPP to keep track of where things came from, OTOH.
Is there a CPP written in Haskell and packaged as a library?
There is "cpphs". As a quick solution, I'd say we run the HOC InterfaceGenerator over the 10.4 SDK in /Developer/SDKs/ (which has all the "old" headers). I'm still working on cleaning up my InterfaceGenerator rewrite (I didn't have enough time to finihs last weekend, so maybe next weekend, but at least I'm motivated now). I think any more more elaborate improvements to the interface generator should be based on that instead of my old code. Cheers, Wolfgang
On Nov 6, 2007, at 6:57 PM, Wolfgang Thaller wrote:
That is not exactly what we want, I think. Currently, HOC parses things file-by-file, so we do NOT want to follow #include directives. We might just process the line pragmas from CPP to keep track of where things came from, OTOH.
You _do_ need to pre-process. Witness the following:
@interface NSWindow : NSResponder
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5
I'm still working on cleaning up my InterfaceGenerator rewrite (I didn't have enough time to finihs last weekend, so maybe next weekend, but at least I'm motivated now).
I'll be waiting anxiously.
I think any more more elaborate improvements to the interface generator should be based on that instead of my old code.
Maybe I can merge my changes when you are ready. What are your improvements to the interface generator? Thanks, Joel -- http://wagerlabs.com
BridgeSupport [1] is new functionality in Leopard that makes the current Haskell Objective-C bindings (HOC) obsolete (almost). --- The metadata is intended to be a resource for use beyond bridging. Most frameworks on the system provide two chunks of XML BridgeSupport metadata; succinct and full. The succinct version contains all of the metadata not provided by the Objective-C runtime (which provides about 80% of what is necessary to do full fidelity calls in / out of Objective-C via libffi). The full version contains just that, the full metadata required to describe the APIs of the framework, including all the bits that could be gleaned at runtime. --- BridgeSupport makes it unnecessary to parse Cocoa headers since all the required data is right there in plain XML [2]. It's no longer necessary to bundle libffi with HOC either since Leopard comes with a much improved version. I hereby propose to close up the old HOC project on SourceForge and set up a new one at GoogleCode. I already did this but GoogleCode noticed the SF project and is now waiting for permission from Wolfgang and Andre. Thanks, Joel [1] http://www.friday.com/bbum/2007/10/27/pyobjc-20-pyobjc-in-leopard/ [2] /System/Library/Frameworks/AppKit.framework/Resources/ BridgeSupport/AppKitFull.bridgesupport -- http://wagerlabs.com
On 7-Nov-07, at 5:14 PM, Joel Reymont wrote:
BridgeSupport [1] is new functionality in Leopard that makes the current Haskell Objective-C bindings (HOC) obsolete (almost).
"Almost" here means about five to ten percent of the code ;-). If the BridgeSupport files really contain all the information we need, then we can indeed drop the Objective-C parsing code from HOC and use a BridgeSupport parser instead. Unfortunately, that parser itself is less than 500 lines out of 7000 (in the HOC library and the InterfaceGenerator taken together). But the sheer beauty of having someone else maintain the parser for us should make it worthwhile. One big piece of information we need that is currently missing from the BridgeSupport files is which declaration comes form which header file. HOC's module structure currently follows Apple's .h files, and we need the module system for resolving naming ambiguities. So either we need to change that, or we need to get the information from elsewhere. There might be other small things missing, we'll have to carefully look at the details.
[...] It's no longer necessary to bundle libffi with HOC either since Leopard comes with a much improved version.
Yes, that's one great little addition to Mac OS X :-).
I hereby propose to close up the old HOC project on SourceForge and set up a new one at GoogleCode. I already did this but GoogleCode noticed the SF project and is now waiting for permission from Wolfgang and Andre.
I haven't had a chance recently to do a thorough comparison of different open source hosting providers, so I have no opinion on this one. So if you want to invest time in maintaining HOC, and you want to maintain it on GoogleCode, then so be it. How do I give my permission? Cheers, Wolfgang
On Nov 7, 2007, at 9:57 PM, Wolfgang Thaller wrote:
One big piece of information we need that is currently missing from the BridgeSupport files is which declaration comes form which header file. HOC's module structure currently follows Apple's .h files, and we need the module system for resolving naming ambiguities.
Why not assume that each class goes into a file of its own and all classes in a directory matching the name of the framework? You will then have AppKit/NSWindow.hs, etc. I think this is how it's done right now. Constants and such can be gathered in AppKit/AppKit.hs.
I haven't had a chance recently to do a thorough comparison of different open source hosting providers, so I have no opinion on this one. So if you want to invest time in maintaining HOC, and you want to maintain it on GoogleCode, then so be it. How do I give my permission?
Either you or Andre should have received an email from Google Code. Please add wagerlabs to the project admins on SourceForge and I'll look into it. Thanks, Joel -- http://wagerlabs.com
participants (3)
-
Joel Reymont -
Malcolm Wallace -
Wolfgang Thaller