sketchucation logo sketchucation
    • Login
    🛣️ Road Profile Builder | Generate roads, curbs and pavements easily Download

    Are Swig generated Ruby bindings compatible with Sketchup?

    Scheduled Pinned Locked Moved Developers' Forum
    13 Posts 7 Posters 3.0k 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

      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