Issue #55 resolved

Devkit not added to path

ezuhaib
created an issue

I have to manually add the devkit bin directory to PATH in Windows. The drawback is that when I switch ruby versions, I have to update the PATH env variable for the new devit/bin directory too.

Comments (6)

  1. jonforums repo owner

    If you're using the RubyInstaller DevKit as a minimal toolchain for building native gems, I think the issue may be your configuration or usage.

    If you've properly installed the DevKit (e.g. - create a config.yml and run ruby dk.rb install) you never need to add the DevKit dirs to your PATH in order to build native gems. Back in 2010 when I wrote the DevKit's dk.rb install script I made it create a RubyGems plugin that automagically adds (temporarily for just the gem build) the DevKit to your PATH everytime you tried to install or upgrade a native gem.

    For example, on my system for ruby 2.1 the generated RubyGems plugin lives in C:\Apps\rubies\ruby-2.1\lib\ruby\2.1.0\rubygems\defaults\operating_system.rb and looks like

    # :DK-BEG: override 'gem install' to enable RubyInstaller DevKit usage
    Gem.pre_install do |gem_installer|
      load 'devkit.rb' unless gem_installer.spec.extensions.empty?
    end
    # :DK-END:
    

    which references the devkit.rb file living in C:\Apps\rubies\ruby-2.1\lib\ruby\site_ruby\devkit.rb that looks like

    # enable RubyInstaller DevKit usage as a vendorable helper library
    unless ENV['PATH'].include?('C:\\DevKit-x32-4.9.0\\mingw\\bin') then
      phrase = 'Temporarily enhancing PATH to include DevKit...'
      if defined?(Gem)
        Gem.ui.say(phrase) if Gem.configuration.verbose
      else
        puts phrase
      end
      puts "Prepending ENV['PATH'] to include DevKit..." if $DEBUG
      ENV['PATH'] = 'C:\\DevKit-x32-4.9.0\\bin;C:\\DevKit-x32-4.9.0\\mingw\\bin;' + ENV['PATH']
    end
    ENV['RI_DEVKIT'] = 'C:\\DevKit-x32-4.9.0'
    ENV['CC'] = 'gcc'
    ENV['CXX'] = 'g++'
    ENV['CPP'] = 'cpp'
    

    The above locations are different on for my ruby 2.0 install with a 4.8.2 based DevKit because I had upgraded RubyGems from it's default value. The concepts are still the same.

    So, with the above setup, I can do things like the following in which I upgrade the native oj gem via uru and have different DevKit versions automagically brought on to PATH dependent upon which ruby install is being upgraded. In this example neither the 4.8.2 nor the 4.9.0 DevKit bin dirs have been manually added to my PATH. The RubyGems plugin does that for each install of oj.

    C:\>uru gem up oj
    
    ruby 2.1.2p93 (2014-05-06 revision 45833) [i386-mingw32]
    
    Updating installed gems
    Updating oj
    Fetching: oj-2.9.0.gem (100%)
    Temporarily enhancing PATH to include DevKit...
    Building native extensions.  This could take a while...
    Successfully installed oj-2.9.0
    Gems updated: oj
    
    ruby 2.0.0p477 (2014-04-30 revision 45762) [i386-mingw32]
    
    Updating installed gems
    Updating oj
    Fetching: oj-2.9.0.gem (100%)
    Temporarily enhancing PATH to include DevKit...
    Building native extensions.  This could take a while...
    Successfully installed oj-2.9.0
    Gems updated: oj
    
    jruby 1.7.12 (1.9.3p392) 2014-04-15 643e292 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13
    +indy [Windows 8.1-amd64]
    
    io/console not supported; tty will not be manipulated
    Updating installed gems
    Nothing to update
    
    
    C:\>uru gem clean
    
    ruby 2.1.2p93 (2014-05-06 revision 45833) [i386-mingw32]
    
    Cleaning up installed gems...
    Attempting to uninstall oj-2.8.1
    Successfully uninstalled oj-2.8.1
    Clean Up Complete
    
    ruby 2.0.0p477 (2014-04-30 revision 45762) [i386-mingw32]
    
    Cleaning up installed gems...
    Attempting to uninstall oj-2.8.1
    Successfully uninstalled oj-2.8.1
    Clean Up Complete
    
    jruby 1.7.12 (1.9.3p392) 2014-04-15 643e292 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_05-b13
    +indy [Windows 8.1-amd64]
    
    io/console not supported; tty will not be manipulated
    Cleaning up installed gems...
    Clean Up Complete
    

    See if installing the DevKit as per the above and using uru as I've described works for you. If not, summarize how you'd like to use them and we'll what makes sense to do.

  2. ezuhaib reporter

    Indeed the PATH is automagically enhanced during gem compilation. However, the same is not true when some rails gems rely on the devkit binaries in runtime, e.g devkit comes with a file.exe binary which is a port from unix-like OS'es and allows gems to use it on Windows systems which do not have it by default. In that case, I'll need to have added the devkit/bin manually to PATH (because no automatic enhancement there).

    So far I'm having to switch between Ruby 1.9.3 and 2.0.0 and such runtime binaries work fine across both rubies so I do not actually have to switch PATH frequently. But that seems to me less than ideal... I thought maybe the moment we type uru 193 , path is enhanced to include the relevant devkit already.

  3. jonforums repo owner

    Since uru targets windows, linux, and osx systems I can't hardcode assumptions about the devkit nor can I assume a canonical devkit install location.

    I'm a bit surprised that some rails gems rely on devkit exes at runtime. Would you spin me up on the specific gems that do this? Maybe we can find something workable with uru.

  4. jonforums repo owner

    I have a potential uru usage "fix" for you. As uru never modifies your base PATH and only prepends values to it, try putting your devkit bindir on PATH before you first use uru. As uru switches your PATH, each ruby will be prepended in turn but your devkit bindir should remain. Try it and everytime you switch to a new ruby type set path to see what I mean.

    I could rant for awhile on how paperclip and other gems only utilizing OS-specific capabilities without fallbacks are doing multi-platform Ruby support wrong and shooting Ruby in the foot. But I'm not going to. It could be a simple oversight on the paperclip devs part, or a conscious tradeoff they've made, or simply inexperienced coding. Regardless, this is a paperclip bug.

    It's this type of behavior that makes make MRI on Windows less viable and, long-term, increases the chances of MRI becoming a nix-only solution for all intents and purposes. For every gem like oj, nokogiri, and psych (notice all are native gems) in which the devs do the hard work to keep the gem multi-platform, it's appalling to see a (non-native?) gem like paperclip force itself into a nix-specific corner. So much for not ranting.

    I dislike the idea of putting the devkit bindir on PATH to workaround the paperclip bug. But if you do it before you first use uru, you should be able to switch rubies and have the devkit artifacts remain on PATH. If this works for you, please close this issue out.

  5. Log in to comment