I work on a Win box, without compiler.
But 'gem environment' gives two PLATFORMs, win32 *and* ruby.
Then 'gem update' try to load the wrong gem...
How may I clean the environment variable ?
Thanks for help...
···
--
Posted via http://www.ruby-forum.com/.
I don't think understand your problem.
gem env reports two platforms: that is correct: take for example this
linux box:
RubyGems Environment:
- RUBYGEMS VERSION: 0.9.5 (0.9.5)
- RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-linux]
- INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
- RUBY EXECUTABLE: /usr/local/bin/ruby
- RUBYGEMS PLATFORMS:
- ruby
- x86-linux
- GEM PATHS:
- /usr/local/lib/ruby/gems/1.8
That means rubygems will try to install gems marked with 'ruby' (also
known as pure ruby gems) or gems that are pre-compiled / binary or
specific for the x86 linux platform.
In your case, x86-mswin32 is a correct platform and RubyGems will try
to install the best gems for you.
What is the output you're having?
More information will be helpful to point directions or bug reports.
···
On Nov 23, 9:48 am, Michel Demazure <mic...@demazure.com> wrote:
I work on a Win box, without compiler.
But 'gem environment' gives two PLATFORMs, win32 *and* ruby.
Then 'gem update' try to load the wrong gem...
How may I clean the environment variable ?
Thanks for help...
Luis Lavena wrote:
I work on a Win box, without compiler.
But 'gem environment' gives two PLATFORMs, win32 *and* ruby.
Then 'gem update' try to load the wrong gem...
How may I clean the environment variable ?
Thanks for help...
I don't think understand your problem.
gem env reports two platforms: that is correct: take for example this
linux box:
RubyGems Environment:
- RUBYGEMS VERSION: 0.9.5 (0.9.5)
- RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-linux]
- INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
- RUBY EXECUTABLE: /usr/local/bin/ruby
- RUBYGEMS PLATFORMS:
- ruby
- x86-linux
- GEM PATHS:
- /usr/local/lib/ruby/gems/1.8
That means rubygems will try to install gems marked with 'ruby' (also
known as pure ruby gems) or gems that are pre-compiled / binary or
specific for the x86 linux platform.
In your case, x86-mswin32 is a correct platform and RubyGems will try
to install the best gems for you.
What is the output you're having?
More information will be helpful to point directions or bug reports.
@Luis
Apparently, 'gem install' selects the wrong gem and loads a gem to be
compiled, see below :
This is new to gem 0.9.5, before I had to choose...
Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:...>gem install rcov
Building native extensions. This could take a while...
ERROR: Error installing rcov:
ERROR: Failed to build gem native extension.
C:/ruby/bin/ruby.exe extconf.rb install rcov
creating Makefile
nmake
'nmake' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
Gem files will remain installed in
C:/ruby/lib/ruby/gems/1.8/gems/rcov-0.8.1.2.0
for inspection.
Results logged to
C:/ruby/lib/ruby/gems/1.8/gems/rcov-0.8.1.2.0/ext/rcovrt/gem_m
ake.out
···
On Nov 23, 9:48 am, Michel Demazure <mic...@demazure.com> wrote:
--
Posted via http://www.ruby-forum.com/\.
Michel Demazure wrote:
Luis Lavena wrote:
I work on a Win box, without compiler.
But 'gem environment' gives two PLATFORMs, win32 *and* ruby.
Then 'gem update' try to load the wrong gem...
How may I clean the environment variable ?
Thanks for help...
I don't think understand your problem.
gem env reports two platforms: that is correct: take for example this
linux box:
RubyGems Environment:
- RUBYGEMS VERSION: 0.9.5 (0.9.5)
- RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-linux]
- INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
- RUBY EXECUTABLE: /usr/local/bin/ruby
- RUBYGEMS PLATFORMS:
- ruby
- x86-linux
- GEM PATHS:
- /usr/local/lib/ruby/gems/1.8
That means rubygems will try to install gems marked with 'ruby' (also
known as pure ruby gems) or gems that are pre-compiled / binary or
specific for the x86 linux platform.
In your case, x86-mswin32 is a correct platform and RubyGems will try
to install the best gems for you.
What is the output you're having?
More information will be helpful to point directions or bug reports.
@Luis
Apparently, 'gem install' selects the wrong gem and loads a gem to be
compiled, see below :
This is new to gem 0.9.5, before I had to choose...
Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:...>gem install rcov
Building native extensions. This could take a while...
ERROR: Error installing rcov:
ERROR: Failed to build gem native extension.
C:/ruby/bin/ruby.exe extconf.rb install rcov
creating Makefile
nmake
'nmake' n'est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
Gem files will remain installed in
C:/ruby/lib/ruby/gems/1.8/gems/rcov-0.8.1.2.0
for inspection.
Results logged to
C:/ruby/lib/ruby/gems/1.8/gems/rcov-0.8.1.2.0/ext/rcovrt/gem_m
ake.out
More to be complete :
RubyGems Environment:
- RUBYGEMS VERSION: 0.9.5 (0.9.5)
- RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
- INSTALLATION DIRECTORY: C:/ruby/lib/ruby/gems/1.8
- RUBY EXECUTABLE: C:/ruby/bin/ruby.exe
- RUBYGEMS PLATFORMS:
- ruby
- x86-mswin32-60
- GEM PATHS:
- C:/ruby/lib/ruby/gems/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://gems.rubyforge.org
···
On Nov 23, 9:48 am, Michel Demazure <mic...@demazure.com> wrote:
--
Posted via http://www.ruby-forum.com/\.
Yes Michel, this was reported and solved for gems marked as 'mswin32'
platform which extend to mongrel, rcov and others.
This problem was discussed on RubyGems development list and this was
fixed in the repository. I guess RubyGems developers are waiting for
more feedback until drop 0.9.5.1 bugfix release.
I'll suggest checkout the repository trunk of RubyGems [1] and perform
the install manually.
I must agree this should have rolled sooner, but catching all the odd
cases with so many platforms is a hard task.
Also, this is a mistake that gem developers used 'mswin32' instead of
using Gem::Platform::CURRENT (almost all, including me).
You can overide that for the time being with:
gem update --platform 'mswin32'
Maybe now 0.9.5 is out, we should start creating _correct_ packages
for it?
[1] http://rubyforge.org/scm/?group_id=126
···
On Nov 23, 2:19 pm, Michel Demazure <mic...@demazure.com> wrote:
Luis Lavena wrote:
> On Nov 23, 9:48 am, Michel Demazure <mic...@demazure.com> wrote:
>> I work on a Win box, without compiler.
>> But 'gem environment' gives two PLATFORMs, win32 *and* ruby.
>> Then 'gem update' try to load the wrong gem...
>> How may I clean the environment variable ?
>> Thanks for help...
> I don't think understand your problem.
> gem env reports two platforms: that is correct: take for example this
> linux box:
> RubyGems Environment:
> - RUBYGEMS VERSION: 0.9.5 (0.9.5)
> - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i686-linux]
> - INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.8
> - RUBY EXECUTABLE: /usr/local/bin/ruby
> - RUBYGEMS PLATFORMS:
> - ruby
> - x86-linux
> - GEM PATHS:
> - /usr/local/lib/ruby/gems/1.8
> That means rubygems will try to install gems marked with 'ruby' (also
> known as pure ruby gems) or gems that are pre-compiled / binary or
> specific for the x86 linux platform.
> In your case, x86-mswin32 is a correct platform and RubyGems will try
> to install the best gems for you.
> What is the output you're having?
> More information will be helpful to point directions or bug reports.
@Luis
Apparently, 'gem install' selects the wrong gem and loads a gem to be
compiled, see below :
This is new to gem 0.9.5, before I had to choose...
Luis Lavena wrote:
Also, this is a mistake that gem developers used 'mswin32' instead of
using Gem::Platform::CURRENT (almost all, including me).
You can overide that for the time being with:
gem update --platform 'mswin32'
Maybe now 0.9.5 is out, we should start creating _correct_ packages
for it?
[1] http://rubyforge.org/scm/?group_id=126
Thanks a lot, Luis. I tried the "correct" form --platform x86-win32-60
and it did not work. I understand now why...
All the best
Michel
···
--
Posted via http://www.ruby-forum.com/\.
Gems with string platforms can no longer be built on 0.9.5. The author will need to make changes to the gemspec, and the exception given should be straightforward.
···
On Nov 23, 2007, at 11:05 AM, Luis Lavena wrote:
Maybe now 0.9.5 is out, we should start creating _correct_ packages
for it?
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars
> Also, this is a mistake that gem developers used 'mswin32' instead of
> using Gem::Platform::CURRENT (almost all, including me).
>
> You can overide that for the time being with:
>
> gem update --platform 'mswin32'
>
> Maybe now 0.9.5 is out, we should start creating _correct_ packages
> for it?
>
> [1] http://rubyforge.org/scm/?group_id=126
Thanks a lot, Luis. I tried the "correct" form --platform x86-win32-60
and it did not work. I understand now why...
Just out of curiousity, how many incorrect options are there? Is this
totally idiot-proof in the new version? I'd be up to write a
gem help windows
docs patch with some simple overview of stuff like that, except my
Windows box is in storage. Deep storage. Practically cryogenic.
···
--
Giles Bowkett
Podcast: http://hollywoodgrit.blogspot.com
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com
$ gem help platforms
[...]
When building platform gems, set the platform in the gem specification to
Gem::Platform::CURRENT. This will correctly mark the gem with your ruby's
platform.
Is that good enough?
···
On Nov 23, 2007, at 14:20 PM, Giles Bowkett wrote:
Just out of curiousity, how many incorrect options are there? Is this
totally idiot-proof in the new version? I'd be up to write a
gem help windows
docs patch with some simple overview of stuff like that, except my
Windows box is in storage. Deep storage. Practically cryogenic.