Repository navigation
Windows, RubyGems, 32 bit, etc #112
Description
Apologies for opening this issue here, as it's not a RubyInstaller2 issue.
Two OSS things I've been looking at are gem bin stubs and fat-binary gems (building on Appveyor) and their use. Any feedback from people active here would be helpful.
-
gem bin stubs - Gem bin stubs are the cmd or bat files (located in
binfolders) that allow commands likerake testto run. The current implementation is not portable, as the path to ruby.exe is hard coded. With my work flow (multiple builds/versions that I'm testing against), I'd prefer if bin stubs inside ofRbConfig::TOPDIRwere relative to RbConfig::TOPDIR, and for those outside (typically--user-installgems), PATH is relied on to resolve where ruby.exe is. See RubyGems PR #2119. There are different opinions as to how this should be fixed... -
fat-binary gems - Given my multiple version/build testing, I often install gems with
--user-install, as that (in theory) allows them to be used with any build with a matching ABI version. The problem occurs when one wants to use/test both 32 bit and 64 bit fat-binaries. My question - is there still a need for 32 bit Windows Ruby builds? Or, is there legacy code on windows that requires people to still use 32 bit Ruby?
Thanks, Greg
Activity
larskanis commentedon Jun 5, 2018
No need to apologize - I'm always pleased to get news from you!
MSP-Greg commentedon Jun 5, 2018
@larskanis
Thanks for the comment. There are pros & cons to whether bin folders outside of RbConfig::TOPDIR should have an absolute path to ruby.exe or simply ruby.exe, but I felt the simple ruby.exe was best.
First of all, thanks for the link (www.somsubhra.com) , as I was unaware of it. I'm in a discussion about an embedded ruby app, and I'm in favor if 2.5 (fully tested mwsin & mingw), while others prefer 2.4. Hard to determine what's more popular or even how to rank them, but people are definitely using 2.5.x.
Re fat-binaries (FB), I'm undecided. Thanks to you for the runtime that allows many people to build locally.
I'm often drawn to edge cases. EventMachine's (EM) FB currently builds for 2.0 thru 2.3. I wanted to extend that to 2.5, and realized it would take four different OpenSSL packages to match the native OpenSSL dll's contained in 2.0 thru 2.5. People with experience building can probably build anything correctly (that can be), but many others cannot. Same for some MacOS or *nix coder trying to cross compile.
I did create some ps1 files for building Puma and EM on Appveyor. The repo with the EM build code is at eventmachine-fb.
One thing I noticed is that most FB's don't have the *.so files stripped. Is that intentional?
Finally, thanks for the response, and hope things are well,
Greg
aharpervc commentedon Jun 7, 2018
I always choose 32bit ruby due to historical (unfounded? cargo culted?) belief that various gems with native dependencies wouldn't work in 64bit. Interesting to hear that this is apparently not a problem for 90% of people. I might not be alone in that assumption. It's possible this was true in the olden days, but if it's not true now then maybe there's room for increased communication that 64 bit is preferred/default.
MSP-Greg commentedon Jun 7, 2018
I'm probably mistaken, but I think if you go back far enough, a 64 bit version of DevKit wasn't available.
FWIW, I work with trunk a lot, so fat-binary extension gems are not available. I have had no problem building/compiling most popular extension gems.
Good idea. Maybe the https://rubyinstaller.org/ home page should have a 'side-bar' heading of '64 or 32 bit?' with a sentence or two...
Thanks Greg
larskanis commentedon Jan 8, 2019
It's there now, so I'm closing this. Thanks!