Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Installation failure on Ruby 1.9.3-p484 #1

Closed
tiredpixel opened this issue Jan 5, 2014 · 8 comments
Closed

Installation failure on Ruby 1.9.3-p484 #1

tiredpixel opened this issue Jan 5, 2014 · 8 comments

Comments

@tiredpixel
Copy link
Contributor

I was wondering, is it intended that this gem work on Ruby 1.9.3-p484 ? I'm aware that it's an extraction of curses from the Ruby standard library (https://bugs.ruby-lang.org/issues/8584), being removed from Ruby 2.1.0 onwards, and that Ruby 1.9.3 already has curses included. On Ruby 2.0.0-p353 it installs fine for me, however, despite curses also being included in that standard library. The problem is with trying to use curses within a separate gem whilst supporting Ruby 1.9.3, 2.0.0, 2.1.0 for that gem. With the Ruby 1.9.3 gem install failure, I can't specify curses as a formal dependency within a gemspec—yet it's needed for the Ruby 2.1.0 support. I've got around it, but I'm interested to learn whether support for Ruby 1.9.3 is intended, and whether perhaps I've missed something. :)

I'm attempting to install on OS X 10.9.1 (13B42) with Xcode 5.0.2 (5A3005), RVM 1.25.14 (master), Gem 2.2.0, Bundler 1.5.1. On Ruby 2.1.0-p0 all seems well with curses gem installed, on Ruby 2.0.0-p353 gem installs without error, on Ruby 1.9.3-p484 I get the following:

$ gem install curses -V
HEAD https://rubygems.org/latest_specs.4.8.gz
302 Moved Temporarily
HEAD https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz
200 OK
GET https://rubygems.org/latest_specs.4.8.gz
302 Moved Temporarily
GET https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz
200 OK
HEAD https://rubygems.org/specs.4.8.gz
302 Moved Temporarily
HEAD https://s3.amazonaws.com/production.s3.rubygems.org/specs.4.8.gz
200 OK
GET https://rubygems.org/specs.4.8.gz
302 Moved Temporarily
GET https://s3.amazonaws.com/production.s3.rubygems.org/specs.4.8.gz
200 OK
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/BSDL
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/COPYING
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/History.md
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/Manifest.txt
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/README.md
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/Rakefile
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/curses.gemspec
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/ext/curses/curses.c
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/ext/curses/depend
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/ext/curses/extconf.rb
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/lib/curses.rb
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/sample/hello.rb
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/sample/mouse.rb
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/sample/rain.rb
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/sample/view.rb
/Users/mlnw/.rvm/gems/ruby-1.9.3-p484/gems/curses-1.0.0/sample/view2.rb
Building native extensions. This could take a while...
/Users/mlnw/.rvm/rubies/ruby-1.9.3-p484/bin/ruby extconf.rb
checking for tgetent() in -ltinfo... no
checking for tgetent() in -ltermcap... yes
checking for ncurses.h... yes
checking for initscr() in -lncursesw... no
checking for initscr() in -lncurses... yes
header: ncurses.h
library: ncurses
checking for beep()... yes
checking for bkgd()... yes
checking for bkgdset()... yes
checking for curs_set()... yes
checking for deleteln()... yes
checking for doupdate()... yes
checking for flash()... yes
checking for getbkgd()... yes
checking for getnstr()... yes
checking for init()... no
checking for init in ncurses.h... no
checking for isendwin()... yes
checking for keyname()... yes
checking for keypad()... yes
checking for resizeterm()... yes
checking for scrl()... yes
checking for set()... no
checking for set in ncurses.h... no
checking for setscrreg()... yes
checking for ungetch()... yes
checking for wattroff()... yes
checking for wattron()... yes
checking for wattrset()... yes
checking for wbkgd()... yes
checking for wbkgdset()... yes
checking for wdeleteln()... yes
checking for wgetnstr()... yes
checking for wresize()... yes
checking for wscrl()... yes
checking for wsetscrreg()... yes
checking for def_prog_mode()... yes
checking for reset_prog_mode()... yes
checking for timeout()... yes
checking for wtimeout()... yes
checking for nodelay()... yes
checking for init_color()... yes
checking for wcolor_set()... yes
checking for use_default_colors()... yes
checking for newpad()... yes
checking for ESCDELAY in ncurses.h... yes
checking for TABSIZE in ncurses.h... yes
checking for COLORS in ncurses.h... yes
checking for COLOR_PAIRS in ncurses.h... yes
checking for function curses_version in ncurses.h... yes
checking for variable curses_version in ncurses.h... no
creating Makefile
make
make: *** No rule to make target /Users/mlnw/.rvm/rubies/ruby-1.9.3-p484/include/ruby-1.9.1/ruby/thread.h', needed bycurses.o'. Stop.
ERROR: Error installing curses:
ERROR: Failed to build gem native extension.

Building has failed. See above output for more information on the failure.

Peace,
tiredpixel
@lnxbil
Copy link

lnxbil commented Jan 21, 2014

got the same error :-/

@tiredpixel
Copy link
Contributor Author

I suspect this might be related to ruby/ruby@c51a826 and ruby/ruby@ce0b4fe (both of which are in branches ruby_2_0_0, ruby_2_1, not ruby_1_9_3). The former saw the creation of the new header file Ruby include/ruby/thread.h (also changing the deprecated rb_thread_blocking_region() to rb_thread_call_without_gvl()). The latter defined HAVE_RUBY_THREAD_H to indicate if Ruby ruby/thread.h is available. This constant is defined in ruby_2_0_0, ruby_2_1, and of course not in ruby_1_9_3.

Curses ext/curses/curses.c specifies #include "ruby/thread.h", and Curses ext/curses/depend lists $(hdrdir)/ruby/thread.h. In ruby_1_9_3, I think that such functionality is contained in Ruby internal.h (rather than Ruby ruby/thread.h). Ruby include/ruby.h and Ruby include/ruby/io.h are present in ruby_1_9_3 however and are referenced in Curses ext/curses/curses.c, so at file-level the functionality is there without the Curses #include "ruby/thread.h". But of course, the file version of Curses ext/curses/curses.c is for a different version; I do not know how difficult (or desired?) it would be to make it backwards-compatible (beyond merely using #ifdef HAVE_RUBY_THREAD_H or similar, I mean).

Which makes me wonder about the broader plans of cross-version compatibility with the extraction of parts of Ruby into gems (such as for this Curses). When something is part of core, of course, it is designed to be compatible with the rest of the code in that version. But once it is extracted to a gem, the question of compatibility becomes even more interesting, because of it being possible to attempt usage of the Ruby trunk version of Curses present in master compiling with Ruby ruby_1_9_3 headers and similar—and, of course, sadness could ensue. Such considerations would make me think that the answer to my original musing—that of whether it is intended that this gem work with Ruby 1.9.3-p484 (etc.)—is 'no' (this is not anything official—merely my wonderings). But that can cause problems for projects using Curses trying to support multiple Ruby versions, some of which use the Curses gem, and some of which don't. Or do I misunderstand entirely; it is intended that such gems will always be installed along with Ruby, so somehow the dependencies never need to be specified at project-level?

@hsbt
Copy link
Member

hsbt commented Feb 1, 2014

This gem supports only Ruby 2.1.0 later. If you use Ruby 1.9.3 or 2.0.0, you don't need to this gem. Please use curses in stdlib.

@hsbt hsbt closed this as completed Feb 1, 2014
@chrisarcand
Copy link
Contributor

Unless you're trying to build a tool using curses that wants to support 1.9.3/2.0.0 AND 2.1.0. Then you appear to be stuck, as I am.

@tiredpixel
Copy link
Contributor Author

@chrisarcand, I too encountered this issue whilst trying to maintain cross-version support in a gem. I'm not entirely happy with what I've done, but in case it's useful to you, this is the commit I applied:
tiredpixel/z.2014-05-28.sidekiq-spy@16ead97
I also put some notes together (author alert):
http://www.tiredpixel.com/2014/01/05/curses-conditional-ruby-gem-installation-within-a-gemspec/
Please feel free to ask if there's something unclear, and I will aim to be of assistance. :)

@chrisarcand
Copy link
Contributor

@tiredpixel Great work, I'll give that work-around a go! With the push to move to Ruby 2+ hopefully this workaround will be temporary anyway. Thanks for sharing!

@chrisarcand chrisarcand mentioned this issue Feb 22, 2014
Closed
@chrisarcand
Copy link
Contributor

This problem persists for me; For @tiredpixel, your gem is used at system-level and that's a great fix - but not as part of a project using Bundler, where if curses it isn't part of the Gemfile.lock it won't be used (bundle exec ...). My gem needs have this curses gem as a dependency for 2.1.0 to work, and specifically not for < 2.1.0 to work.

I think it rather silly to have separate versions for this awkward version break. As this is simply supposed to be a modularization of the former curses stdlib, it's frustrating that this isn't backwards compatible at all. I'm poking around the extension, but I'm unfamiliar and unsure how difficult this would be. Seems like this should at least allow installation in 1.9.3 until support for 1.9.3 is dropped next year.

@tiredpixel
Copy link
Contributor Author

@chrisarcand, thank you for your information on- and off-list. I have been investigating the matter, and would value your feedback to what I describe in sportngin/opsicle#22 (comment) .

This was referenced Feb 23, 2014
Closed
Merged
chrisarcand added a commit to sportngin/opsicle that referenced this issue Feb 23, 2015
@chrisarcand
Remove needless dependency management
68d8926 
The curses gem was updated to allow for noop requires, meaning when you
require it with ruby < 2.1.0 it doesn't explode anymore.
ruby/curses#1
chrisarcand added a commit to sportngin/opsicle that referenced this issue Feb 23, 2015
@chrisarcand
Remove needless dependency management
7ec9673 
The curses gem was updated to allow for noop requires, meaning when you
require it with ruby < 2.1.0 it doesn't explode anymore.
ruby/curses#1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@hsbt @lnxbil @tiredpixel @chrisarcand