Despite looking thoroughly for similar topics or in the doc, I could not find satisfactory answer to my problem.
I am developing an extension relying on some external libs (in an .so file). I understood (and my tests have shown) that the libs need to be compiled with some specific Ruby version to be compatible with corresponding SketchUp versions. That’s fine.
My question is, when it comes to submitting the the extension for publishing, which version shall be submitted to the team? only the one compatible with the most recent SU version or all of them? if yes to the latter, is there a specific way of packaging them?
All of them. Ie the RBZ package must be 100% complete as if you were going to only publish it unencrypted.
(But if you check the box for encryption on the signing portal, the signed RBZ returned will be encrypted.)
The easiest way is to have subfolders named for the ruby versions beneath platform folders.
… and then build your loading paths with File::join
# From a file **within** your extension's subfolder ...
os =( Sketchup.platform == :platform_win ? 'win' : 'mac' )
ver = RUBY_VERSION.to_f.to_s
# Load the library files, omitting file type ...
this_lib = File.join( __dir__, os, ver, 'this_lib' )
require this_lib
that_lib = File.join( __dir__, os, ver, 'that_lib' )
require that_lib
Ruby maintains ABI compatibility between major.minor versions. Hence, an *.so file that works with Ruby 2.7.2 will work with any Ruby version 2.7.x, assuming a platform match.
Hence, rather than using RUBY_VERSION.to_f.to_s, I might suggest either
Both of the above are used in ‘pre-compiled’ extension gems.
Also, note that with Windows, the below transition is a change from mingw to mswin builds…
SU 2020 2.5.5 mingw
SU 2021 2.7.2 mswin
EDIT: Want to make clear that what Dan suggested will work fine (RUBY_VERSION.to_f.to_s) with all current released versions of Ruby.
I have an aversion to treating version data as a numeric sequence, as truncating zeros can lead to incorrect data, eg, ‘3.10’ may be converted to ‘3.1’. No Ruby versions have been released with a minor version greater than 9, so in practice, treating the major.minor string as a float is ok.