[Rubyinstaller-devel] Mac OS installer

Mark Hubbart discordantus at gmail.com
Tue Oct 18 15:20:50 EDT 2005

On 10/18/05, Curt Hibbs <curt.hibbs at gmail.com> wrote:
> I've cc'd this back to the mailing list to keep everyone up to date. I also
> cc'd Rich Kilmer because he'd like to see Apple pick this up to be part of
> their official distribution, and he has some internal Apple contacts that
> could possibly make this a reality.
>  See the rest of my response below...
>  On 10/18/05, Mark Hubbart <discordantus at gmail.com> wrote:
> > On 10/17/05, Curt Hibbs <curt.hibbs at gmail.com> wrote:
> > > Don't update for 1.8.3 -- its got bugs in it. Better to stick with
> 1.8.2.
> >
> > Thanks for the tip. I never updated to 1.8.3 myself, and am glad to
> > know that I'm not missing anything :) Still, 1.8.3 comes with an
> > entirely different build mechanism for the extensions. If core
> > continues to use it for future versions, I'll need to be looking into
> > it.
>  Whenever you're ready to release something based on 1.8.2, let's call it a
> preview (or something similar), because Matz will be releasing 1.8.4 at the
> end of the year and we'll want to make the official release use 1.8.4.
> > I worked on the project this evening, to see what still needs to be
> > done. I discovered that most of the work ahead is just on features. I
> > fixed all but one of the bugs that were slowing me down, so as soon as
> > I swat this last one, I think I'll be able to do some sort of a
> > release.
> >
> > This last bug is causing a segmentation fault when rdoc generates
> > documentation for installed gems. I'm a bit stymied, but I'll keep
> > working on it. C just isn't my thing.
> >
> > I need to figure out where I can use help on this project... The
> > framework code and copious patches might be a bit daunting to someone
> > unfamiliar with ruby internals (it's daunting to me), and once I get
> > the framework working bug-free, packaging it should be the easy part.
>  I didn't realize that you had to patch Ruby. What are the nature of these
> patches?

Only one C patch, which adds a RUBY_FRAMEWORK_VERSION constant
alongside RUBY_VERSION et al. The rest are config, makefile and
extconf patches. Ruby itself was *almost* flexible enough to do what
was needed, but not quite. In the future, there may need to be more C
patches, but I'm not sure. Basically, some directories needed to be
moved around, header files relocated, and support for frameworks
added. GNU Readline will be included in the distribution as well, as a
separate framework.

> Are these things that we should submit back for incorporation into
> Ruby?

They aren't clean enough right now, but yes, it would be nice to get
framework build support built in. I'd need to get clean stable patches
that work with the latest 1.8.x version, though.

> > Also, as I've said, I haven't worked on many collaborative projects
> > before, so I'm unsure of how to work this :/
>  I don't know James or Patrick's skills, but an example could be to help
> track down the seg-fault if they were already up to speed.
>  They could also serve as alpha tester by downloaded and installing what
> you've got now. They might run into problems that are easily addressed now
> when you'd only have 2 users instead of after the release when there would
> be hundreds.

After working on that segfault, I'm not sure I can track it down
myself. I'll work on packaging up what I have, which works pretty well
right now (with a few caveats).

>  They could also work on incorporating the extensions that we want to
> bundle. I advocate keeping it to a minimum, but some just make sense (like
> RubyGems and RubyCocoa).

I agree. I have a version of RubyCocoa that will build against the
framework; RubyGems works, so that opens up a lot of available

I'll let you know when I have something (hopefully later this afternoon :)


>  Curt
> > Anyway, this made me find some time to get some work done on the
> > project, so I'll count my blessings :)
> >
> > cheers,
> > Mark
> >

More information about the Rubyinstaller-devel mailing list