Patchwork [0/4] ruby: Add from OE-Classic and update to 1.9.3-p194

login
register
mail settings
Submitter jackie huang
Date Oct. 9, 2012, 6:36 a.m.
Message ID <cover.1349689653.git.jackie.huang@windriver.com>
Download mbox
Permalink /patch/37947/
State New
Headers show

Pull-request

git://git.pokylinux.org/poky-contrib jhuang0/r_ruby_20121008_2

Comments

jackie huang - Oct. 9, 2012, 6:36 a.m.
From: Jackie Huang <jackie.huang@windriver.com>

* I sent this months ago but was told that oe-core is not the right place,
  however, we think it makes sense to add ruby to complete the scripting
  language set of: python, perl, ruby, so I re-send it.

* Test info
  1) IMAGE_INSTALL_append += "ruby"
  2) $ bitbake core-image-sato
  3) $ runqemu
  4) simple runtime tests: 

root@qemuppc:~# ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [powerpc-linux]

root@qemuppc:~# ruby -e 'puts "Hello World"'
Hello World

root@qemuppc:~# gem -v
1.8.23

root@qemuppc:~# wget http://rubygems.org/downloads/term-ansicolor-1.0.7.gem
Connecting to rubygems.org (204.232.149.25:80)
Connecting to rubygems.org (204.232.149.25:80)
Connecting to production.cf.rubygems.org (54.240.160.224:80)
term-ansicolor-1.0.7 100% |*******************************| 16896   0:00:00 ETA
root@qemuppc:~# ls
term-ansicolor-1.0.7.gem
root@qemuppc:~# gem install term-ansicolor-1.0.7.gem
Successfully installed term-ansicolor-1.0.7
1 gem installed
Installing ri documentation for term-ansicolor-1.0.7...
Installing RDoc documentation for term-ansicolor-1.0.7...
root@qemuppc:~# gem list

*** LOCAL GEMS ***

bigdecimal (1.1.0)
io-console (0.3)
json (1.5.4)
minitest (2.5.1)
rake (0.9.2.2)
rdoc (3.9.4)
term-ansicolor (1.0.7)

 
  

The following changes since commit bcefd015fb163d9c382ae05a86569dbcfd3d736a:

  oe-buildenv-internal: Add BB_NO_NETWORK to BB_ENV_EXTRAWHITE (2012-10-07 13:13:52 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib jhuang0/r_ruby_20121008_2
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=jhuang0/r_ruby_20121008_2

Jackie Huang (4):
  libyaml: Add recipe from meta-oe
  libyaml: update to 0.1.4
  ruby: Add from OE-Classic
  ruby: update to 1.9.3-194

 meta/recipes-devtools/ruby/ruby.inc                |   37 +++
 ...onf-hardcode-wide-getaddr-info-test-outco.patch |   26 ++
 meta/recipes-devtools/ruby/ruby/extmk.patch        |   13 +
 meta/recipes-devtools/ruby/ruby/extmk_run.patch    |   15 +
 .../ruby/ruby/ruby-1.9.3-always-use-i386.patch     |   11 +
 .../ruby/ruby/ruby-1.9.3-bignum-test-fix.patch     |   31 ++
 .../ruby/ruby-1.9.3-custom-rubygems-location.patch |   86 ++++++
 .../ruby/ruby-1.9.3-disable-versioned-paths.patch  |  149 ++++++++++
 .../ruby/ruby/ruby-1.9.3-fix-s390x-build.patch     |   12 +
 .../ruby/ruby/ruby-1.9.3-install-cross.patch       |   16 +
 .../ruby/ruby/ruby-1.9.3-mkmf-verbose.patch        |   11 +
 .../ruby-1.9.3-rubygems-1.8.11-uninstaller.patch   |   76 +++++
 .../ruby/ruby/ruby-1.9.3-webrick-test-fix.patch    |   24 ++
 .../ruby/rubygems-1.8.11-binary-extensions.patch   |  296 ++++++++++++++++++++
 meta/recipes-devtools/ruby/ruby_1.9.3-p194.bb      |   57 ++++
 meta/recipes-support/libyaml/libyaml_0.1.4.bb      |   17 ++
 16 files changed, 877 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-devtools/ruby/ruby.inc
 create mode 100644 meta/recipes-devtools/ruby/ruby/0001-socket-extconf-hardcode-wide-getaddr-info-test-outco.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/extmk.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/extmk_run.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-always-use-i386.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-bignum-test-fix.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-custom-rubygems-location.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-disable-versioned-paths.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-fix-s390x-build.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-install-cross.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-mkmf-verbose.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-rubygems-1.8.11-uninstaller.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/ruby-1.9.3-webrick-test-fix.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby/rubygems-1.8.11-binary-extensions.patch
 create mode 100644 meta/recipes-devtools/ruby/ruby_1.9.3-p194.bb
 create mode 100644 meta/recipes-support/libyaml/libyaml_0.1.4.bb
Paul Eggleton - Oct. 9, 2012, 10:38 a.m.
Hi Jackie,

On Tuesday 09 October 2012 14:36:53 jackie.huang@windriver.com wrote:
> From: Jackie Huang <jackie.huang@windriver.com>
> 
> * I sent this months ago but was told that oe-core is not the right place,
>   however, we think it makes sense to add ruby to complete the scripting
>   language set of: python, perl, ruby, so I re-send it.

I have to say, my opinion is the same now as it was then. Ruby support is 
certainly useful to have, and we have had requests for it; but unlike Perl and 
Python which are needed by many other things, nothing we have in OE-Core 
actually needs Ruby; thus it really belongs in another layer IMHO.

Cheers,
Paul
Ross Burton - Oct. 9, 2012, 12:38 p.m.
On 9 October 2012 11:38, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>> * I sent this months ago but was told that oe-core is not the right place,
>>   however, we think it makes sense to add ruby to complete the scripting
>>   language set of: python, perl, ruby, so I re-send it.
>
> I have to say, my opinion is the same now as it was then. Ruby support is
> certainly useful to have, and we have had requests for it; but unlike Perl and
> Python which are needed by many other things, nothing we have in OE-Core
> actually needs Ruby; thus it really belongs in another layer IMHO.

Agreed.  If we're completing the set of scripting languages there's
plenty left out.  A standalone meta-ruby layer that contains the
runtime and pretty much every useful library sounds like a much better
idea as the runtime and the libraries will be in a single place and
incompatible changes can be done in a single move without having to
co-ordinate multiple layers.

Ross
Khem Raj - Oct. 9, 2012, 5:07 p.m.
On Oct 9, 2012, at 3:38 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> Hi Jackie,
> 
> On Tuesday 09 October 2012 14:36:53 jackie.huang@windriver.com wrote:
>> From: Jackie Huang <jackie.huang@windriver.com>
>> 
>> * I sent this months ago but was told that oe-core is not the right place,
>>  however, we think it makes sense to add ruby to complete the scripting
>>  language set of: python, perl, ruby, so I re-send it.
> 
> I have to say, my opinion is the same now as it was then. Ruby support is 
> certainly useful to have, and we have had requests for it; but unlike Perl and 
> Python which are needed by many other things, nothing we have in OE-Core 
> actually needs Ruby; thus it really belongs in another layer IMHO.
> 

I guess yes reluctantly, unless we have two different ruby apps which show
up in different layers then we have a stronger case.

> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
jackie huang - Oct. 10, 2012, 1:46 a.m.
On 10/9/2012 8:38 PM, Burton, Ross wrote:
> On 9 October 2012 11:38, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>>> * I sent this months ago but was told that oe-core is not the right place,
>>>    however, we think it makes sense to add ruby to complete the scripting
>>>    language set of: python, perl, ruby, so I re-send it.
>>
>> I have to say, my opinion is the same now as it was then. Ruby support is
>> certainly useful to have, and we have had requests for it; but unlike Perl and
>> Python which are needed by many other things, nothing we have in OE-Core
>> actually needs Ruby; thus it really belongs in another layer IMHO.
>
> Agreed.  If we're completing the set of scripting languages there's
> plenty left out.  A standalone meta-ruby layer that contains the
> runtime and pretty much every useful library sounds like a much better
> idea as the runtime and the libraries will be in a single place and
> incompatible changes can be done in a single move without having to
> co-ordinate multiple layers.

I see, thanks, so I think I should send it to meta-oe at this point.

Thanks,
Jackie

>
> Ross
>