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

Developers Ruby API
1

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 LayOutRubyAPI.so. 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.

2

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 ?

3

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…

john

4

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
5

At lunch I updated the SU dev copy:

RUBY_DESCRIPTION

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…

6

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

7

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

8

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…

john

1 Like
9

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.