Jonathan Paisley
jp-ww****@dcs*****
Fri Mar 17 00:06:14 JST 2006
On 16 Mar 2006, at 14:37, kimura wataru wrote: >> From my point of view, I wouldn't ever want an end-user of an >> application to have to install RubyCocoa to get it to work. Since I >> also want to use ruby 1.8, I'm happy bundling the ruby runtime and >> any needed support files along with the RubyCocoa framework. This >> approach allows an app to run on 10.4 and 10.3. >> > like this? > > RubyCocoa.framework/ > RubyCocoa # binary module of the framework > Resources/ > ruby/.. # libraries of RubyCocoa > lib/libruby.dylib > lib/ruby/1.8/.. # libraries of ruby That would work but perhaps brings in more overhead than necessary for bundling with an application (since all the *.rb files and any *.bundle are included, even if they're not used). However, the RubyCocoa.framework could always be trimmed after putting inside an application bundle, so that's not really a problem. An advantage of bundling our own Ruby interpreter is that we could pre-patch it with support for using Ruby threads with Cocoa (using my patch). Furthermore, the problem with using standaloneify.rb at the moment is that it can pull in other DarwinPorts libraries from /opt/local/lib, whereas I'd prefer the ruby used with RubyCocoa to be built with as few non-Apple dependencies as possible. Therefore, perhaps it would be worth looking into building a standard ruby-1.8.4 with the 10.3.9 SDK and bundling that with RubyCocoa? Even if RubyCocoa later gets bundled with OSX, I think I'd prefer to distribute apps that are completely standalone. What do you think?
