From: Jason Roelofs <jameskilton@...>
Date: 2009-08-03T21:52:08+09:00
Subject: Re: Fwd: ruby_frame in 1.8 is what in 1.9?

--0016e64eabf4b314dd04703c3c6d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Aug 3, 2009 at 8:41 AM, Roger Pack <rogerpack2005@gmail.com> wrote:

> > I will, once I can get this thing built. What is the deal with Ruby
> > 1.9.1 /
> > 1.9.2 no longer including certain header files in the install?
>
> >
> > yuck! What is up with this and can we get this decision reversed? Or is
> > there another way around this?
>
> One option would be to create a "ruby sources" gem that includes the
> *.h, *.inc files from "each known patch number" of ruby.
> a la
> require 'ruby_sources'
> RubySources.source_directory_for_current_ruby # =>
> '/lib/gems/ruby_sources/include/ruby-1.9.1-p129' or what not
>
> Then the question becomes "should said gem include the full source or
> just the headers"? [it probably wouldn't hurt much at all to include the
> full sources--disk space is cheap, right?].
> Thoughts?
> =r
> --
> Posted via http://www.ruby-forum.com/.
>
>
I like the idea for sure, though I doubt we need the entire source, just all
the headers would suffice. And going with other *nix tools, while having a
call in ruby would be nice, I'd also put together a command-line tool like:

/usr/bin/ruby_includes [--for=version_string]     where version_string are
things like "1.9.1" "1.9.2" and probably need "1.9.2p[patch]" depending on
if headers change for a patch level.

I wonder how these kind of libraries are handled in other languages like
Python or Perl, if they also have to build work-arounds or if internals of
the language are readily available.

Jason

--0016e64eabf4b314dd04703c3c6d--