sketchucation logo sketchucation
    • Login
    ℹ️ Licensed Extensions | FredoBatch, ElevationProfile, FredoSketch, LayOps, MatSim and Pic2Shape will require license from Sept 1st More Info

    Are Swig generated Ruby bindings compatible with Sketchup?

    Scheduled Pinned Locked Moved Developers' Forum
    13 Posts 7 Posters 2.9k Views 7 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • thomthomT Offline
      thomthom
      last edited by

      @metasim said:

      (matching the 1.8.5 that appears to be in Sketchup currently)

      I thought it was 1.8.0 ...

      Thomas Thomassen — SketchUp Monkey & Coding addict
      List of my plugins and link to the CookieWare fund

      1 Reply Last reply Reply Quote 0
      • thomthomT Offline
        thomthom
        last edited by

        Checked in SU7.1 just to be sure they haven't updated it:

        ` Object::RUBY_VERSION

        1.8.0`

        Thomas Thomassen — SketchUp Monkey & Coding addict
        List of my plugins and link to the CookieWare fund

        1 Reply Last reply Reply Quote 0
        • RunnerPackR Offline
          RunnerPack
          last edited by

          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 😄

          You might have noticed... I'm a bit of a ferpectionist.

          1 Reply Last reply Reply Quote 0
          • M Offline
            metasim
            last edited by

            @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

            1 Reply Last reply Reply Quote 0
            • J Offline
              Jim
              last edited by

              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?

              Hi

              1 Reply Last reply Reply Quote 0
              • M Offline
                metasim
                last edited by

                @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 helps 😄

                Actually 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

                1 Reply Last reply Reply Quote 0
                • thomthomT Offline
                  thomthom
                  last edited by

                  @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 PC

                  Wonder why the different platforms has different builds...

                  Thomas Thomassen — SketchUp Monkey & Coding addict
                  List of my plugins and link to the CookieWare fund

                  1 Reply Last reply Reply Quote 0
                  • M Offline
                    metasim
                    last edited by

                    @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

                    1 Reply Last reply Reply Quote 0
                    • M Offline
                      metasim
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • M Offline
                        MaistorKokir
                        last edited by

                        @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 😄

                        1 Reply Last reply Reply Quote 0
                        • D Offline
                          DavidBluecame
                          last edited by

                          @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.
                          Simeon

                          Hello,

                          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! 😄

                          1 Reply Last reply Reply Quote 0
                          • 1 / 1
                          • First post
                            Last post
                          Buy SketchPlus
                          Buy SUbD
                          Buy WrapR
                          Buy eBook
                          Buy Modelur
                          Buy Vertex Tools
                          Buy SketchCuisine
                          Buy FormFonts

                          Advertisement