Fw: Re: [RubyInstaller] Shoes and RubyInstaller
- 2011-09-21 @ 18:17
A few comments below before heading off to a meeting :(
> [cross-posted to RubyInstaller]
> I'm helping Steve Klabnik get the Shoes recipes updated to use the
latest RubyInstaller so we can cut a new release of Shoes for Windows
using MRI 1.9.2. He and I got together last week and started looking
through the old RubyInstaller fork  that handled the build and
comparing it to the latest RubyInstaller master. There has been quite a
bit of divergence between the two codebases in the last 2 years.
This divergence will continue to be a maintenance problem for you,
especially if we ever transition to using Luis'
I hope we can figure out something that more modularly slides into the
current structure in order to minimize merge conflicts for you.
> 1. Dependencies
> The hardest problem is making sure all of the dependencies for Shoes are
built. It appears that all dependent libraries *must* be listed in
config/ruby_installer.rb. I assume that the default task of rake is to
make sure all of these dependencies are downloaded, extracted, prepared,
etc. and ready for linking in the PATH (or maybe not... see #5 below).
We centralize configuration in a few key modules (eg - RubyInstaller) for
use by the actual deps recipes in recipes/dependencies. So yes, it's
probably a good thing to add Shoes dep config info in
config/ruby_installer.rb and try to do the work in a
recipes/dependencies/shoes.rake and any funky patches you may need in
A potentially cleaner option is to bypass updating
config/ruby_installer.rb as Shoes-specific stuff really doesn't belong
there, and update rakefile.rb to pull in config/shoes.rb similar to how I
did `require config/devkit`
> 2. Checkpoint
> The #checkpoint method is called before most work in the dependencies
recipes is executed. It looks like the return value of the call to
#checkpoint is a Rake::Task instance. This was non-obvious to me and took
a few minutes to figure out.
> I interpret the use of #checkpoint as a way for each recipe to enhance
the common tasks needed to build any library. Instead of subclassing a
rake task, it can be extended via customization. Then after these
customizations are done, the work is finished off by a call to a top-level
task (:download, :extract, :prepare, :configure, :compile, :install) with
the newly customized task as a dependency.
Also make sure you're comfortable with what
> 3. Shoes Dependencies
> We need to make new recipes for these libraries:
> readline (though the new RubyInstaller uses rbreadline)
Why readline instead of rb-readline? IIRC, readline with MRI on Windows
needlessly consumes CPU cycles. Search the ML and perhaps Luis' blog.
Another potential gotcha is that since we use the DevKit (MSYS, MinGW)
build recipes internally to build deps and MRI source, some of your deps
may not build if they need toolkit artifacts we don't currently provide.
You may need to make tweaks to what I do in:
or you may want to define your own DevKit flavor and tweak
and add something like shoes_kit.rb to config/compilers and update
> 4. Modify config/ruby_installer.rb
> The URL, file names, sandbox paths and a few other details all need to
be added to config/ruby_installer.rb following the format of the existing
As I mentioned in #1, I'd patch the existing rakefile.rb to pull in a
custom config/shoes.rb where you do your Shoes configuration.
I'm sure we'll flush out a bunch more when Luis jumps in and we get more
Most people die of a sort of creeping common sense, and discover when it
is too late that the only things one never regrets are one's mistakes.
- Oscar Wilde