Make dk.rb support x64 ruby

[petemounce]

I was having difficulty installing ruby & devkit via chocolatey. ruby dk.rb init was not finding the installed ruby (which for reference gets put into c:/tools/ruby200).

I was attempting this on Windows 2012 R2 x64, in AWS, via eu-west-1 ami-6abd621d.

• Chocolatey 0.9.8.27
• ruby via chocolatey package 2.0.0.48100 (latest at time)
• ruby devkit via chocolatey package 4.7.2.2013022401 (latest at time)

I discovered that the install-location is stored in a slightly different search path on the machine that I installed to. I assume this is an x86/x64 difference, but don't really know enough about that area to be certain.

My test consisted of

• choco install ruby
• choco install ruby2.devkit
• edit dk.rb as in the diff
• run ruby dk.rb init from c:/devkit2 (which is where chocolatey puts it)
• observe that it has generated config.yml with the install-location to my ruby (c:/tools/ruby200, where chocolatey puts that)
• run ruby dk.rb install and then the standard test using json gem; success

[luislavena]

@petemounce thank you for looking into this and working out a solution!

I tried to look into this issue in #178 but seems I failed to find a good solution for it.

Can you test against a installer build from the repository instead of latest released one? If not, no worries, I'll try later today and confirm your solution works.

Thank you once again for looking into this and taking the time for sending a patch! ❤️ ❤️ ❤️

[petemounce]

@luislavena My pleasure; hope it works against a recent build.

I'm afraid I don't have an environment to build the installer from source against which to test, though, sorry (I'm on holiday at the moment, and only have basic connectivity).

[jonforums]

@luislavena the hand-edit-of-dk.rb testing that @petemounce did should be fine for the following reasons:

• No one has updated your tweak of my original rubinius and jruby registry placeholder reg key locations as per this blame
• The diff only changes a static part of the dk.rb.erb template.
• No one has updated my original 2011 Inno script for reg keys for RubyInstaller version info. I still believe Inno does the 32/64 registry swizzling behind the scenes as it did before.

The concerns I have are:

1. Capitalization of Software should be consistent; pick one.
2. Did the hand-edited dk.rb test have the # encoding: UTF-8 header comment to workaround codepages?
3. Does the hand-edit dk.rb test also need to be run on a non-english version of 64bit windows? It is likely OK, but I don't have access to a non-english version to spelunk the registry and/or test to verify.

[luislavena]

@jonforums I had done some testings locally for changes to the registry simply because InnoSetup didn't record the information properly (see the related ticket I included before).

The codepage issue was Ruby itself (win32/registry) and not RubyInstaller.

In relation to non-english, all the registry keys we use are the same across versions, no change.

Will take a look to this later today and let you guys know.

[petemounce]

The capitalisation of "software" was a copy/paste on my part from what I saw. Here's a screengrab.

[XhmikosR]

👍 for this. I tested on my Windows 7 64-bit VM and works fine.

[petemounce]

@Azolo What can I do further to get this merged?

[Azolo]

Honestly, I just hadn't thought about it since my first glance.

So, yeah pinging me was enough.

Sorry about that and thank you very much for the contribution.

[XhmikosR]

Thanks for this. Do you plan to release a new DevKit version?

[Azolo]

I don't have any plans to.

There are a lot of things that were going on but have stalled.
I need to get a handle on those and some other things before I look into doing that.

[XhmikosR]

OK, no worries. I just noticed that the DevKit is hardly updated and this change, while not very important, I'm pretty sure affects many people nowadays.

[Azolo]

@XhmikosR Yeah, the DevKit is a pretty rough beast. I do think that there are better ways to distribute it and maybe even build it. Currently though, I'm reluctant to change it or even update it because it does have a pretty massive ripple effect.

Once I figure out a way to make that easier then I do think that updating the DevKit will be a more common thing.

[petemounce]

What things are currently painful?

Sent from my phone. Please excuse typos and brevity, but never text speak.
On 30 Apr 2015 22:30, "Justin Baker" notifications@github.com wrote:

@XhmikosR https://github.com/XhmikosR Yeah, the DevKit is a pretty
rough beast. I do think that there are better ways to distribute it and
maybe even build it. Currently though, I'm reluctant to change it or even
update it because it does have a pretty massive ripple effect.

Once I figure out a way to make that easier then I do think that updating
the DevKit will be a more common thing.

—
Reply to this email directly or view it on GitHub
#237 (comment)
.

[Azolo]

A simple change like this is really not a big deal, but it's still not easy to release either. It does mean that I need to manually change a bunch stuff in various places, which is just a pain to keep track of it all. Even more so because I have to look through to make sure I've done everything I need to do. Since I didn't originally create the process this is a huge time sink for me. I also can't just supplant the existing version because there are probably programs and such out there relying the checksums to stay the same.

Precedent is pretty much that there have been very few releases of DevKits period. The only new DevKit release for the years that I've been using RubyInstaller have been with the release of Ruby 2 and that was switching to a new toolchain. So taking that into consideration, I am only more apprehensive of the process.

Those are the things for a release on a change like this. Changing something more substantial these are the pain points:

Versioning is one of the big things I don't like. Since the DevKit is just a set of tools it's version is based off the version off the distribution and version of the gcc toolchain we use with the build date appended.

Releasing a patch would just be just changing the date stamp on whatever version. Which would be fine, but adding new functionality would require an upgrade for anyone that uses it. I imagine that people are like me and immediately just disregard the timestamp when extracting DevKits into a folder, and there's no way to tell which version I have once it's extracted.

The other thing that is painful is I don't completely understand how the different versions of the compiler toolchain work. So I am extremely conservative on making any changes until I get some good feedback from people I trust and/or provide compelling evidence that I should and can change something without breaking it.

Finally, almost every gem that provides binaries, as in don't require the DevKit to compile extenstions, is cross-compiled in a *nix environment using a compiler toolchain that is based off of the DevKit toolchain. So a change has to be coordinated and verified as working by those tools.

If you've gotten through this wall of text, Thank you for reading. I'm glad you asked the question though because I haven't actually had to put it into words until now.