Are Swig generated Ruby bindings compatible with Sketchup?
-
@metasim said:
(matching the 1.8.5 that appears to be in Sketchup currently)
I thought it was 1.8.0 ...
-
Checked in SU7.1 just to be sure they haven't updated it:
` Object::RUBY_VERSION
1.8.0`
-
I'm going to provide my "armchair CS major" version of what I think is going on.
I've had some experience with SWIG and Ruby extensions and, from what I've read, the wrapper/extension has to be linked to the same libruby that was linked with the ruby runtime, i.e. the executable called "ruby" (or "ruby.exe" for the win32 version) in a stand-alone installation.
In SketchUp's case, the environment is inside the SketchUp executable, and the libruby included (in my SU7.1/win32 install) is 'msvcrt-ruby18.dll'.
So, what you need to do is find out how to link against a 1.8.0 version of the ruby library. It goes without saying that said library also has to be compiled for the same machine/OS as the one SU is using. Actually, the one extension I compiled for SU was linked against the 1.8.7 version of "msvcrt-ruby18.dll" and still worked (well, it didn't actually work, but that was because it also used OpenGL for graphics, but it didn't crash SU, at least).
Ideally, you would link to the actual library included in the SU installation. I think on OSX it would be called "libruby-1.8.dylib" (or something like that).
Of course, having absolutely no experience with OSX, I don't know how to deal with things like multiple processor architecture support and such, or even whether that applies to this situation .
A bit long-winded, but I hope it helps
-
@thomthom said:
Checked in SU7.1 just to be sure they haven't updated it:
` Object::RUBY_VERSION
1.8.0`
I should have been clear about versions:
I'm running Sketchup 7.1 (7.1.4870) on MacOS 10.5.8. This is what I get from the ruby console:
> Object::RUBY_VERSION 1.8.5
-
I thought SketchUp used the already installed Ruby on Macs, and ships with a .dll on Windows?
What happens when a Mac user upgrades to Ruby 1.9? Do the differences between platforms continue to diverge when in fact they need to unite?
-
@runnerpack said:
...
Ideally, you would link to the actual library included in the SU installation. I think on OSX it would be called "libruby-1.8.dylib" (or something like that).
...
A bit long-winded, but I hope it helpsActually it helps quite a bit. Pointing out that the ruby runtime was "minimalist" is a good hint. On MacOS the libraries, resources, etc. are provided as "Framework" bundles. Normally a Framework bundle contains the header files and libraries, and older versions of Sketchup had the "minimalist" header files. Now even those are missing, leaving the Framework bundle as mostly empty directories with the exception of a single file called "Ruby", which is (confusingly) the shared library and not the interpreter (no idea why they leave the extension off in Frameworks).
So that's my long-winded way of saying that your arm-chair analysis gives me a coule things to try out Thanks!
Simeon
-
@metasim said:
@thomthom said:
Checked in SU7.1 just to be sure they haven't updated it:
` Object::RUBY_VERSION
1.8.0`
I should have been clear about versions:
I'm running Sketchup 7.1 (7.1.4870) on MacOS 10.5.8. This is what I get from the ruby console:
> Object::RUBY_VERSION 1.8.5
That's interesting...
I'm using SU7.1.4871 on PCWonder why the different platforms has different builds...
-
@jim said:
I thought SketchUp used the already installed Ruby on Macs, and ships with a .dll on Windows?
...While Ruby is included in modern MacOS versions, applications can have their own versions (of most any library) in their application bundle. In this case it's "SketchUp.app/Contents/Frameworks/Ruby.framework". Compared to the system Ruby Framework, it's very sparse:
Sketchup.app/Contents/Frameworks
Ruby.framework Ruby.framework/Resources Ruby.framework/Ruby Ruby.framework/Versions Ruby.framework/Versions/A Ruby.framework/Versions/A/Resources Ruby.framework/Versions/A/Resources/English.lproj Ruby.framework/Versions/A/Resources/English.lproj/InfoPlist.strings Ruby.framework/Versions/A/Resources/Info.plist Ruby.framework/Versions/A/Ruby Ruby.framework/Versions/Current
/System/Library/Frameworks
Ruby.framework Ruby.framework/Headers Ruby.framework/Resources Ruby.framework/Ruby Ruby.framework/Versions Ruby.framework/Versions/1.8 Ruby.framework/Versions/1.8/Headers Ruby.framework/Versions/1.8/Headers/config.h Ruby.framework/Versions/1.8/Headers/defines.h Ruby.framework/Versions/1.8/Headers/digest.h Ruby.framework/Versions/1.8/Headers/dl.h Ruby.framework/Versions/1.8/Headers/dlconfig.h Ruby.framework/Versions/1.8/Headers/dln.h Ruby.framework/Versions/1.8/Headers/dtrace.h Ruby.framework/Versions/1.8/Headers/env.h Ruby.framework/Versions/1.8/Headers/intern.h Ruby.framework/Versions/1.8/Headers/missing.h Ruby.framework/Versions/1.8/Headers/node.h Ruby.framework/Versions/1.8/Headers/re.h Ruby.framework/Versions/1.8/Headers/regex.h Ruby.framework/Versions/1.8/Headers/ruby.h Ruby.framework/Versions/1.8/Headers/rubyio.h Ruby.framework/Versions/1.8/Headers/rubysig.h Ruby.framework/Versions/1.8/Headers/st.h Ruby.framework/Versions/1.8/Headers/util.h Ruby.framework/Versions/1.8/Headers/version.h Ruby.framework/Versions/1.8/Resources Ruby.framework/Versions/1.8/Resources/English.lproj Ruby.framework/Versions/1.8/Resources/English.lproj/InfoPlist.strings Ruby.framework/Versions/1.8/Resources/Info.plist Ruby.framework/Versions/1.8/Resources/version.plist Ruby.framework/Versions/1.8/Ruby Ruby.framework/Versions/1.8/usr Ruby.framework/Versions/1.8/usr/bin Ruby.framework/Versions/1.8/usr/bin/erb Ruby.framework/Versions/1.8/usr/bin/gem Ruby.framework/Versions/1.8/usr/bin/gem_mirror Ruby.framework/Versions/1.8/usr/bin/gemlock Ruby.framework/Versions/1.8/usr/bin/gemri Ruby.framework/Versions/1.8/usr/bin/gemwhich Ruby.framework/Versions/1.8/usr/bin/irb Ruby.framework/Versions/1.8/usr/bin/rdoc Ruby.framework/Versions/1.8/usr/bin/ri Ruby.framework/Versions/1.8/usr/bin/ruby Ruby.framework/Versions/1.8/usr/bin/testrb Ruby.framework/Versions/1.8/usr/bin/update_rubygems Ruby.framework/Versions/1.8/usr/lib Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib Ruby.framework/Versions/1.8/usr/lib/libruby.dylib Ruby.framework/Versions/1.8/usr/lib/ruby Ruby.framework/Versions/1.8/usr/share Ruby.framework/Versions/1.8/usr/share/ri Ruby.framework/Versions/Current ... (continues for ~37,000 more lines)
The fact that Google doesn't include the header files that it used in its version of the ruby runtime makes it a little bit tricky to compile with Swig (and cmake, in my case); you kinda have to mix and match Framework components.
Simeon
-
Success!
Forcing the linking of the shared library in Sketchup.app was the trick (can't just add it to the library search path).
For other cmake users, here's the CMakeLists.txt fragment that did the trick:
CMakeLists.txt
... find_package(Ruby REQUIRED) if(HAVE_SKETCHUP) set(SKETCHUP "/Applications/Google\ SketchUp\ 7/SketchUp.app") set(SKETCHUP_RUBY "${SKETCHUP}/Contents/Frameworks/Ruby.framework") set(SWIG_RUBY_LIB "${SKETCHUP_RUBY}/Ruby") else() set(SWIG_RUBY_LIB "${RUBY_LIBRARY}") endif() swig_add_module(${RUBY_MODULE_NAME} ruby "${INTERFACE_FILES}") include_directories(${RUBY_INCLUDE_PATH}) swig_link_libraries(${RUBY_MODULE_NAME} "${MYEXTENSION_LIB}" "${SWIG_RUBY_LIB}") ...
Interestingly, when linking against this, MacOS is smart enough to encode the path to the Ruby library relative to the executable, so that if Sketchup.app is installed in a different location, it still works fine:
otool -L MyExtension.bundle
@executable_path/../Frameworks/Ruby.framework/Versions/A/Ruby (compatibility version 1.8.0, current version 1.8.5) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
I hope someone else finds this useful. I'm glad I don't have to resort to a client/server type implementation and associated headaches.
Thanks for all your help!
Simeon
-
@metasim said:
Success!
Forcing the linking of the shared library in Sketchup.app was the trick (can't just add it to the library search path).
For other cmake users, here's the CMakeLists.txt fragment that did the trick:
CMakeLists.txt
> ... > find_package(Ruby REQUIRED) > if(HAVE_SKETCHUP) > set(SKETCHUP "/Applications/Google\ SketchUp\ 7/SketchUp.app") > set(SKETCHUP_RUBY "${SKETCHUP}/Contents/Frameworks/Ruby.framework") > set(SWIG_RUBY_LIB "${SKETCHUP_RUBY}/Ruby") > else() > set(SWIG_RUBY_LIB "${RUBY_LIBRARY}") > endif() > > swig_add_module(${RUBY_MODULE_NAME} ruby "${INTERFACE_FILES}") > include_directories(${RUBY_INCLUDE_PATH}) > swig_link_libraries(${RUBY_MODULE_NAME} "${MYEXTENSION_LIB}" "${SWIG_RUBY_LIB}") > ... >
Interestingly, when linking against this, MacOS is smart enough to encode the path to the Ruby library relative to the executable, so that if Sketchup.app is installed in a different location, it still works fine:
otool -L MyExtension.bundle
> @executable_path/../Frameworks/Ruby.framework/Versions/A/Ruby (compatibility version 1.8.0, current version 1.8.5) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) >
I hope someone else finds this useful. I'm glad I don't have to resort to a client/server type implementation and associated headaches.
Thanks for all your help!
Simeon
Thx Simeon ... Someone else did find this useful
-
@metasim said:
Success!
[...]I hope someone else finds this useful. I'm glad I don't have to resort to a client/server type implementation and associated headaches.
SimeonHello,
I've taken the time to register in SketchEducation just to be able to thank you for this excellent tip. Thanks to you I've been able to succeed after many headaches with my .bundle Swig/CMake generated Ruby/Sketchup extension files causing segfaults every time I used "require" to load them.
Linking against the Sketchup 2016 embedded Ruby library solved the problems and now I can use the extension!!
It was extremely useful. Thank you very much!
Advertisement