librelist archives

« back to archive

Fw: Re: [RubyInstaller] Shoes and RubyInstaller

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 [1] 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 is 

> 3. Shoes Dependencies
> We need to make new recipes for these libraries:
> cairo
> git
> glib
> libjpeg
> libpng
> libungif
> pango
> port_audio
> readline (though the new RubyInstaller uses rbreadline)
> sqlite3
> winhttp

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 
OpenStruct templates.

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 


twitter: @jonforums

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