[Openmcl-devel] Nominally definitive guide to updating from CVS

[Gary Byers]

I just tried this on a machine with the final version of Leopard installed
and things seemed to work:

1) download 
<ftp://clozure.com/pub/testing/ffigen-apple-gcc-5363-x86-64.tar.gz>

I don't remember whether the executables in that file were compiled
on Tiger or on a Leopard prerelease; if it was built on Leopard it
should work fine on Tiger but a Leopard build might not work under
Tiger.  Since this is mostly of interest to people running Leopard,
that's a minor issue ...

The sources used to build that (given Apple's gcc-5363 release)
are also in that directory.  The "sources" consist mostly of a huge
patch file and a Makefile that applies the patch, builds a modified
GCC frontend, then copies that frontend, a shell script, and some
header files to the archive.

2) extract the archive into a directory that has a bin subdirectory
that's on your shell's search path.  For example, I keep some
executable programs in /usr/local/bin, so I did:

shell> sudo tar xvfz ffigen-apple-gcc-5363-x86-64.tar.gz -C /usr/local

If you keep ~/bin on your shell's search path, then just extracting
the archive into your home directory would also work; the important
thing is that bin/h-to-ffi.sh from the archive should wind up
where your shell can find it and the ffigen directory from the
archive should be a sibling of that bin directory.

(If people wonder why Andrew's been answering lots of questions
lately ... well, he was an English major.)

The header files that're packaged in the archive are "compiler
specific" headers; a program might include a standard system
header file <float.h>, and that file might say (using a GCC
extension)

#include_next "float.h".

The "next" include file is the compiler/platform-specific one
which defines things like (in this example) how many bits are
in a double float; the answer might depend on some combination
of what hardware's available and what compiler options were
provided.

The Makefile that built the "ffigen" archive neglected to
copy at least one such "compiler-specific" header that's
referenced when processing the Cocoa headers.  If you have
xcode installed, you can do:

shell> cp /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/syslimits.h /usr/local/ffigen/include

(You may need to change the target directory above if you extracted
things to some location other than /usr/local.)

Once that's there, start up a (relatively recent) OpenMCL and do:

? (ccl:create-interfaces :cocoa)
;[Running interface translator via #P"ccl:darwin-x86-headers64;cocoa;C;populate.sh.newest" to produce .ffi file(s) from headers]
+++ /Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/objc-runtime.h
+++ /Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/objc-exception.h
+++ /Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Object.h
+++ /Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Protocol.h
/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Protocol.h:46: warning: `unavailable' attribute ignored
/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Protocol.h:50: warning: `unavailable' attribute ignored
+++ /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h


The warnings about ignored attributes are relatitively harmless; there are
other uses of __attribute__ and some uses of @property in some ObjC 
header files that the translator has more trouble with; the ObjC 2.0
language has changed a little in the last 15 months or so.  When Apple
releases the source to the version of GCC used on Leopard, it'll be
ppssible to generate a new ffigen translator (from a much smaller
patch) that has a more accurate knowledge of current ObjC 2.0 syntax.

That stage of the process translated .h files to .ffi files.

CREATE-INTERFACES generates some more output:

;[Parsing .ffi files; may create new .cdb files for :COCOA]
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/objc-exception.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/objc-runtime.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Object.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Protocol.ffi" ...

and then does it again and returns T.

;[Parsing .ffi files again to resolve forward-referenced constants]
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/objc-exception.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/objc-runtime.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Object.ffi" ...
#P"/usr/local/src/ccl/darwin-x86-headers64/cocoa/C/Developer/SDKs/MacOSX10.5.sdk/usr/include/objc/Protocol.ffi" ..

Because of the not-quite-right ObjC 2.0 issues, the translator chokes
harder on some other ObjC frameworks (WebKit); I think that it's possible
to build QTKit interfaces by #defining some @property/__attribute__ thing
to be the empty string.

It's also possible that some other compiler-specific headers (besides
syslimits.h) need to be copied from the GCC support directory to
ffigen/include


On Wed, 31 Oct 2007, Raffael Cavallaro wrote:

>
> On Oct 30, 2007, at 8:31 PM, Gary Byers wrote:
>
>> I may have been hallucinating; I tried again (with headers from
>> the last beta I had from early October) and it worked fine.
>
> Any chance of a Nominally Definitive Guide to Updating the Cocoa Interface 
> Files?
>
> regards,
>
> Ralph
>
>
>
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro at mac.com
>