You're right; I don't want to use rubygems in a desktop app, I don't think that is the purpose of Rubygems and is not a good use case. Rubygems is still quite useful when I want to write a quick script that uses a gem, or when I simply want to experiment with a gem in irb, which is one case for compiling gems when installed via rubygems (but perhaps not a strong case). I am using rubygems with MacRuby for a few small projects that do not (at the moment) belong to a desktop app, and are meant to be libraries distributed as gems and/or embedded in a larger project; not unlike how control_tower is distributed as a gem, and recently the dispatch stuff also became a gem (and probably other gems that I do not know about). I think there is a question here about how MacRuby specific libraries should be built and distributed (best practices?). I've tried to create a framework in Xcode where the library is written using MacRuby, such as a ControlTower.framework, but I am an Xcode n00b so I can't figure out what I am doing wrong, and there are no templates for such an Xcode project. Looking at the macruby_deploy script, it seems that gems get copied into the embeded MacRuby framework, and so they won't get compiled with the rest of the app since macruby_deploy only compiles compiles *.rb files it finds in Contents/Resources. However, if the gems were compiled before the embedding, I think the macruby_deploy script would blindly copy the compiled files in the app bundle; so that would be another case for a rubygems plugin (but I only learned this in the last couple of hours). Though there are also good reasons to put the gem compiling logic in macruby_deploy; such as stripping out things like test scripts and gemspec files that are normally bundled in a gem. This is turning out to be a much more complicated topic than I thought it would be. lol -- Mark Rada mrada@marketcircle.com On 2011-02-19, at 3:21 PM, Matt Aimonetti wrote:
Hey Mark, I think this is an interesting concept but I would encourage you to work on the macruby deploy tool instead. The reason why I'm saying that is that you probably don't wantto use rubygems in a desktop app, instead you probably want to unpack a gem and it's deps in the app you ship. Trunk already supports this option but in a very naive way and I don't think it compiles the gems.
What do you think?
- Matt
Sent from my iPhone
On Feb 19, 2011, at 11:19, Mark Rada <mrada@marketcircle.com> wrote:
Hey,
I recently wrote a small plugin for rubygems that will use the MacRuby compiler to compile *.rb files when you install a gem.
It is usable, but very simple right now; I would like to make it more powerful in a few different ways and I'm not sure which would be good. Things I think I could do (I have not looked at the rubygems source code in depth yet, so I'm not sure what I am allowed to do using the proper API):
- A gemspec property (e.g. spec.compile_for_macruby = true) - A gem command: gem compile nokogiri gem compile —remove-original-files nokogiri • I can’t remove the original *.rb files and leave *.rbo files by default because of how rubygems identifies gems (unless I modify gemspec files) - A gem install option gem install —compile nokogiri
I’m not sure which is best, perhaps all of them will get implemented, but I was wondering what the communities thoughts were about compiling gems; especially since the gemspec option won't work if the community never uses it.
The repo is located at https://github.com/ferrous26/rubygems-compile
-- Mark Rada mrada@marketcircle.com
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel