[Rubyinstaller-devel] Re: FXRuby and the (new) Ruby Installer for OS X

Stephen Steiner ssteiner at mac.com
Mon Aug 16 18:44:49 EDT 2004

> Most of the packages we want to include, though, can be built on OS X
> without fink or darwinports.  I just build all my stuff (ruby, etc) 
> directly
> with apple's toolchain.

Yes, they can.

>> Unfortunately I'm going to have to write some stuff (in Ruby, of
>> course) to get
>> my approach to work since I can't find a tool that does what I want.
> It would be cool for you to elaborate on your tools ideas here.

I'm thinking of installing everything to a virgin OS X install, then 
building the
package directory structure to match the diff of my result and a fresh 
install.  That way every file gets included no matter where it lands.

> Typically with OS X the problems fall along major version boundaries 
> (10.x)
> and not along the minor ones.  That is, unless you make assumptions of
> libraries that are in a later version being in an earlier version (like
> readline, etc).

I'm more concerned with ./configure 'making assumptions' based on what
I have on my system.  Unfortunately, there's no way to really automate
building on different versions of OS X; you have to manually restart 
the system
although that might not be entirely true, now that I think about it.  
There must
be a way to set the boot partition programatically but it's still a 

>> 2>  This is really the only potential hangup.  I'm running OS X 10.3.5
>> and, if I were to
>> configure/make on my system, there's a chance that the result wouldn't
>> run on an earlier version.
> Apple may be able to help us here, or I could just invest in a few more
> firewire drives and install the old versions for testing.  Truly 
> though, you
> most need to support the current major release (currently Panther) and 
> the
> prior major release (currently Jaguar) with testing on the next release
> (Tiger).

How could Apple help?

Yes, most important is current and future.

>> I can make images for a couple of OS X versions but things quickly
>> escalate and,
>> due to the the sheer number of possible permutations, quickly becomes
>> unmanageable.
> This may be a big issue when it comes to extension that you want to 
> include
> in a one-click installer.  If you limit those extensions to a bare few 
> with
> a RubyGems graphical installer for other extensions (maybe built on
> RubyCocoa) then we could offer gems that are platform specific binaries
> (jaguar, panther, tiger, etc).

I'm feeling a maintenance headache coming on...  The more levels of 
we throw in here the worse things are going to get.

>> Also, testing each installation/OS Version is time consuming.
> It is, one good thing to do would be to build a test suite that 
> minimally
> tests all the bundled packages for operational use...unit tests, etc, 
> that
> would cross these installers.

Another huge task and enormously time-consuming (or CPU consuming,
at least) step before a release.

>> I'm probably being overly paranoid here but I really wouldn't like to
>> give users a
>> bad impression of Ruby by having an incompatibility between OS X
>> versions
>> look like a Ruby problem.
> Possibility, but worse would be that they never got a chance to use 
> Ruby at
> all ;-)

Ruby's already installed on the system (1.6.8).  We _could_ just install
stuff to work with that release although that does limit us somewhat.

>> I've noticed that many of the binary distributions  have specific
>> downloads for specific
>> OS X versions (Tcl/Tk Aqua has separate versions for 10.1, 10.2, and
>> 10.3 to use
>> your example).
> Right...those are the major versions...

I think I may just end up building the Panther version and let's see who
cares about other versions.  I'm planning on making the build process
fully automatic so it should be no big deal to just run it on another
OS version.

>> I would like to clear up a misperception: OS X ships with the 
>> developer
>> tools.  There is no need to download the developer tools unless the 
>> version of OS X is
>> so old (10.1 from the beginning of 2001) that Ruby itself won't build 
>> properly with the
>> included tools.
> They do, but I cannot imagine someone who is not a developer actually 
> having
> to install the developer toolchain.  Oh, and the disks that ship are 
> current
> with the OS first released, but subsequent releases update the 
> developer
> toolchain and that is only available online, not through apple's 
> software
> update system.

Ah, yes.  I forgot about the lack of Software Update support.  Good 

>>>    We should probably add RubyCocoa to the list of included 
>>> extensions.
>> Ok!  RubyCocoa, BTW, will be darn close to useless without the
>> developer tools.
> For the developer, that is true.  But if as a developer you created a
> RubyCocoa app that you just wanted to deliver, and that app could 
> require
> the install of the one-click OS X for operation, then is would have 
> high
> value.

Good point, too.

> Additionally, although without the toolchain you cannot build NIB
> files for serialized Uis, you can use RubyCocoa to access AppleScript, 
> Apple
> Events, and manually build Uis without NIBs.

Yuck!  I get your point, however.

>> I have come up with a pretty good way to do the installler package and
>> I'm researching
>> fink and DarwinPorts to see if any of their tools might be helpful.
> Just please don't make yourself dependent on them from a 'runtime'
> perspective.

What do you mean by that?

>> I'll be very interested to hear RIch's thoughts on this.

And, I was right, I was!


More information about the Rubyinstaller-devel mailing list