On 1/10/02 1:19 PM, "Chris Gehlker" <gehlker / fastq.com> wrote:

> On 1/10/02 1:23 PM, "Phil Tomson" <ptkwt / shell1.aracnet.com> wrote:
> 
>> 
>> I'm looking at an article at:
>> http://www.osnews.com/story.php?news_id=498
>> 
>> that says that basically Cocoa is the name for the OpenStep API and that
>> while MacOSX implements Cocoa on the Mac Platform, GnuStep brings Cocoa to
>> Linux on the x86.
>> 
>> So, my question is:  Could RubyCocoa be used under GnuStep on Linux?
>> I suspect that the answer is no right now, because there is probably some
>> C extention involved that is Mac specific. Could the RubyCocoa installer
>> be made such that the installer determines which platform it is running on
>> and if it is Linux it installs a shared library compiled for Linux instead
>> of the one for Mac?  If this could be done, then it seems that we could
>> develop (in Ruby anyway) GUI apps that would run on both MacOSX and Linux
>> (if you have GnuStep installed).  This could be very useful allowing Linux
>> users to develop platform neutral Cocoa apps that run on both platforms.
> 
> I'm poking around in the RubyCocoa source right now trying to see why this
> wouldn't work. I can't see anything. The Cocoa API is all pure ObjC so
> that's not a problem.
> 
> The ObjC linker, dyld, still supports fat binaries so the installer problem
> doesn't even come up. The program will cache and link the right code at run
> time.
> 
> There are obviously some minor issues such as having to conditionally
> compile around AltiVec code and the fact that some Mac programs count of the
> file system being case preserving but insensitive but these seem like pretty
> small potatoes and don't have anything to do with Ruby.

In theory, it's possible to do this, but it would be a significant amount of
work with things as they stand.

The big technical problem (assuming that GNUstep perfectly replicates the
Cocoa API, which I'm pretty sure it doesn't currently) is that the GNU
Objective-C runtime and the NeXT Objective-C runtime -- although
conceptually related -- are completely different in both API and
implementation.

There's already a Ruby interface to GNUstep, called RIGS. It would be much
easier to coordinate RubyCocoa with RIGS to reduce the number of
incompatible source code conventions. (All of RubyCocoa is within an "OSX"
module, for example -- I don't know how RIGS is organized).

I suspect you'll need to wait until GNUstep's interface is a bit closer to
Cocoa, though.

Another alternative would be to write an abstraction layer that sits on top
of both RIGS and RubyCocoa, isolating and bridging the differences between
them. That could be a lot of work, however.

(BTW, A "fat binary" in Mac OS X parlance is a binary archive that contains
one Mach-O file for each CPU architecture that the developer wants to
support. Linux uses ELF executables, not Mach-O, so fat binary support is
not helpful for this purpose.)

Chris