For devs only - anyone want to test with Ruby 2.7 ('daily builds') and SU 2019?

I’ve got two 2019 installs, one is ‘stock’ (ruby 2.5.5), and one is running Ruby 2.7. When 19.2 was released, I went through the process again, and also wrote a ps1 script to push the Ruby files into SU. From my perspective, doing so is a test of both SU and 2.7, but I’ve never had any issues.

I’ve only done this on Windows, so I don’t know what it would take on macOS, but I suspect the process would be similar.

Only two SU files need to be changed/edited, Sketchup.exe and Both have a single reference to 'x64-msvcrt-ruby250.dll`, which needs to be changed to whatever Ruby version is being used. I continue to use both the ‘stock’ version and the new one, so they don’t seem to interfere with each other.

But, if one is wants to work with extension/compiled gems in both versions, that can get tricky, but it’s not impossible. One would need the equivalent of a pre-compiled gem, which I’m familiar with building. Or, as I’ve done, set SU to also have access to the RubyGems --user-install folder, which is ‘versioned’

Doing this also gives one a ‘stand-alone’ version of Ruby 2.7.0 to use.

If anyone is interested, I can throw the ps1 file and a README on GitHub…

Note that one could also do this for Ruby 2.6 releases.

[disclaimer] The Ruby ‘daily build’ package is built three times a day in the cloud (Appveyor), and is used by several popular gems for CI testing. It is also used by some of the std-lib gems for testing. I am the owner of the GitHub repo that builds it.

When we used to do this testing newer Ruby builds / versions in the 1.8 trunk, we’d just change the name of the DLL file. (I had a cmd script that renamed the SU distributed DLL, and then renamed the newer version DLL to the name that SU wanted to load.)

The Mac editions use a frameworkized Ruby in a framework folder hierarchy. It’s been a long while since we discussed this, but somewhere there is a entry that points at the exact framework build subfolder for SketchUp to load.

Perhaps @john_drivenupthewall or @slbaumgartner can weigh in ?

when SU used system Ruby on the mac and a shipped version on windows, myself and a few others would point SU at other ruby builds…

since the move to shipped Ruby ‘parity’, I haven’t jumped thru those hoops again…

however, there seems to be some differences in the two versions and knowing those would be of interest…


As I recall, back then, the std-lib wasn’t included. Today, it is, and all the extension std-lib *.so files reference the Ruby dll. Hence, it would work, but much of the std-lib wouldn’t load…

1 Like

At lunch I updated the SU dev copy:


SU 2019 standard
ruby 2.5.5p157 (2019-03-15 revision 67260) [x64-mingw32]

SU 2019_m
ruby 2.7.0dev (2019-08-05T15:56:05Z master c9192ef2e8) [x64-mingw32]

Yes, the format for RUBY_DESCRIPTION has changed in the trunk/master branch…

hm… was it every using a system Ruby? Didn’t think so. It was just a different version…

I agree. Mac SketchUp always came with it’s own frameworkized Ruby.
Some geeks would point SU at their system Ruby instead.

although it had a ‘shipped’ Ruby in the framework, that used the user ruby library installed by system…

this is from the SU v6 Ruby Config file in it’s Ruby.framework…

#define RUBY_LIB "/usr/local/lib/ruby/1.8"
#define RUBY_SITE_LIB "/usr/local/lib/ruby/site_ruby"
#define RUBY_SITE_LIB2 "/usr/local/lib/ruby/site_ruby/1.8"
#define RUBY_THIN_ARCHLIB "/usr/local/lib/ruby/1.8/fat-darwin8.8.0"
#define RUBY_SITE_THIN_ARCHLIB "/usr/local/lib/ruby/site_ruby/fat-darwin8.8.0"
#define RUBY_PLATFORM "fat-darwin8.8.0"
#define RUBY_ARCHLIB "/usr/local/lib/ruby/1.8/fat-darwin8.8.0"
#define RUBY_SITE_ARCHLIB "/usr/local/lib/ruby/site_ruby/1.8/fat-darwin8.8.0"

the framework had no lib folder and is only 1.5MB…

whenever Apple changed up it’s version of Ruby, SU would only run correctly if you had “/usr/local/lib/ruby/1.8”…

it was the only way to test against older versions of SU or to newer version of ruby…


1 Like

That looks to be from a C header or source file - it would only be used during compilation, not run-time.
That’s probably just some left-over files from when it was compiled.