Since SketchUp got acquired by Trimble the team has made sure to keep the Ruby interpreter embedded in the application somewhat up to date.
We’ve chosen a conservative update cadence since every upgrade require extensions with Ruby C extensions to recompile their binaries. We’ve also chosen use a version that has had time to soak, allowing for the version to stabilize as much as possible before we ship it with the application.
The Ruby 2.x version branch stopped at Ruby 2.7. Moving forward it’s Ruby 3.x.
Any major version upgrade require some extra attention, but the good news is that in our experience the upgrade from Ruby 2.7 to 3.1 was much the same as any minor version upgrade (at least of you heeded the warnings Ruby might have given you in the past.)
This time we’re trying something new; we’re making header and libraries to compile against available much earlier than before. There is no SketchUp build available to test, but simply being able to setup your build environment will help those that need to rebuild their binaries. We created a
dev/3.1 branch in our Ruby C Extension example:
We’ve collected a few notes on our own experience on using Ruby 3.1:
- The upgrade process for building against Ruby 3.1 felt similar to the process of upgrading between previous Ruby 2’s minor upgrades. If you addressed warnings you’re probably good to go.
- We did try to use Ruby 3.0 at first, because we thought it would have had more time to soak up changes and possibly be less disruptive given it’s a major version upgrade. But it turned out that there were more compatibility issues for Ruby C extensions (and SketchUp itself) with Ruby 3.0 compared to 3.1. It appear that the Ruby community smoothened out some API compatibilities with Ruby 2.x between these versions.
- On macOS we had to add
declspecto “Other C Flags” in X-Code:
- We didn’t encounter any breaking changes in pure Ruby extensions that we tested.
- In my case (thomthom), the majority of the work was that Ruby 3.x finally removed the
Win32APIthat had been deprecated since Ruby 1.9. I finally had to switch to
Fiddle(which is a much better API btw.). If you are curious you can have a look at TT_Lib to get an idea of what I did: Bitbucket In order to aid this migration work I first wrote a set of TestUp tests against the existing code. Then I split the old and new implementation into separate implementation files which I could replace upon load depending on SketchUp/Ruby version. This made it a lot easier to ensure that my new
Fiddleimplementation behaved the same as the old
It’s worth giving the release notes for Ruby 3.0 and 3.1 a read.
Ruby-3.0.0 finishes the transition to UTF-8 as the primary character encoding on Windows. This enables full Unicode character set for filesystem and environment variables and increases compatibility with other tools and operating systems.
Enabled ruby to support path length of more than 260 characters. See commit 829ab9d Added racc, rbs and typeprof executables to the /bin folder. See #231
RubyInstaller-3.1.0-x64 has a changed C-runtime called UCRT replacing the old MSVCRT. The modern C-runtime brings better compatibility to C standards and to libraries compiled with Microsoft Visual Studio. See the feature request here. There are several platform strings that change with the new release. In particular the ruby and gem platform is now x64-mingw-ucrt instead of x64-mingw32 and the MSYS2 package prefix is now mingw-w64-ucrt-x86_64-. The Devkit version of RubyInstaller now bundles the UCRT based MINGW packages. ridk install can be used to install these packages into a previous or a shared location of MSYS2. There are some subsequent issues like seamless integration into Github Actions and cross compiler support regarding UCRT.
If you have ever used TypeScript you’ll be familiar with Type Definition files. Ruby 3 introduces it’s own variant of this. This in the form of a new fileformat;
.rbs. Those of you that have been around for a while might recognize that as the file format for the old scrambled Ruby files that SketchUp previously offered. While we no longer offer this fileformat, it’s still found in older extensions that will continue to work and that users still use, so SketchUp continues to read these files for compatibility.
This presents a challenge for developers who would like to make use of this new type definition feature in Ruby. The type definition files aren’t something you’d distribute with your extension, but it is something you’d have along your
.rb files while developing. At the moment this would cause issues for SketchUp because when you perform a
Sketchup.require it will look for
.rb files in that order. If you are using the Ruby 3
.rbs files SketchUp would attempt to load that as a scrambled Ruby file, which off course won’t work.
Upcoming version of SketchUp will be smarter in terms of handling
.rbs files, it will sniff out the headers of the files and decide if it’s a scrambled Ruby file or of it’s a Ruby 3.x type definition.
For more information about Ruby 3.x’s type definition files refer to the various documentation and articles out there.