Best practice to support multiple SketchUp versions?

I developed a plugin using the SketchUp 2018 SDK. The plugin actually uses the Ruby API to interact with the open model but it also uses the SDK to export SKP files. So the end result after compiling is a .so or .bundle Ruby C Extension that calls various functions that are part of the SketchUp SDK.

Now I want to add compatibility for SketchUp 2017. Unfortunately, my plugin is currently utilizing some SDK functions that were only added in the SU 2018 version. That’s OK, the functions aren’t critical but I’d still like to use them for SU2018+.

In order to support SU2017, is the proper way to build a separate .so file (and create a new Visual Studio configuration) that uses pre-processor directives to compile different code based on whether the configuration is set to support SU2017 or not?

I see that the SDK has a method ‘SUGetAPIVersion’ that can probably tell me which SU version is currently running, but I expect I’ll get load errors if I compile my .so that has any references to future functions that don’t yet exist in the SDK for SU2017.

Ideally, I would be able to support both SU2017 and SU2018+ using the same .so file. Is this even possible if the code includes references to SU2018-only functions?

Lastly, do I need to use the SU2017 SDK .lib files when building for 2017 or can I keep using 2018? In my initial tests, building with the 2018 .lib files did not cause any noticeable errors. If you think I should be using the SU2017 SDK files to build, can someone please post a link to download them?

I hope this all makes sense. Thanks!

1 Like

While I’m not the person to answer your query. I love your extensions! Thank you Dale.

1 Like

As far as Ruby is concerned, both v17 and v18 use Ruby 2.2 so they can both load the same so file. But you’d need to compile a separate so for v19 that uses Ruby 2.5.1.

The newer SDK should be able to read older version SKP files even using the latest functions.

Running a Ruby C extension under live SketchUp is a question for @thomthom or @bugra.

You might be able to load the “new” 2018 functions dynamically using GetProcAddress (and the macOS equivalent), which would allow you to check if those are available. If you link with the 2018 link library (.lib) and your code is referring to symbols that do not exist in 2017, then I don’t think your .so will even load in 2017. So you’d have to link with 2017 .lib and handle the new 2018 functions dynamically.

The most straightforward solution is to make separate builds in my opinion.

1 Like

Thanks Bugra, do you know where I can get the SDK (.lib) files for 2017?

Hmm I’m not sure if those are still available now that I think about it. But if you are carefully loading those “new” functions purely dynamically, it won’t matter, you can still use the latest .lib. The linker won’t be linking them from the lib and your .so should still load in 2017.

Are you linking against sketchup.lib or SketchUpAPI.lib? The former links to the C API within Sketchup.exe, the latter links against the standalone version. Mixing those two doesn’t work well.

If you need to use features from the C API released with SU2018 with older versions you have to look into some other way of communicating with the C API.

I’m afraid that function was neglected for a long time so it’s not reliable for older versions I’m afraid.

That should be fine - the main thing to keep in mind is that if you link against the version of the SDK that SketchUp shipped with (sketchup.lib) then you must be careful not to call new functions from older versions.

An alternative you can try is to make a CLI executable that links against the standalone C API. If you only use the SDK to write SKP files it shouldn’t be that much more work to get it working - call your executable with an output path.

If you use the SDK to read from a live model then that becomes a challenge.

Thanks Thom and Bugra. I appreciate the advice