| 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_2Comments
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
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
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
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 >
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