[Tutorial] SketchUp Ruby C Extension

chyn2000

So, I have to apologize for wasting your time...

First thing I need to do (yet again) is RTFM.

The answer to threading is incredibly simple:
_beginthread( silly, 0, (void*)12 );

becomes

rb_thread_create( silly, (void*)12);

found it on:
http://ruby-doc.org/docs/ProgrammingRuby/html/ext_ruby.html

So, if you will excuse me, I need to go beat myself half to death...

thomthom

You will not get any joy from using Ruby threads. They are "green" threads. It's just Ruby dividing up the tasks itself - not the system. So making a thread in Ruby will not prevent SU from freezing.

Parallelism is a Myth in Ruby - igvita.com

(www.igvita.com)

Dan Rathbun

And Daniel Berger's win32-thread package that wraps native threads is still Alpha and unstable (AFAIK.)

jefftrull

I'm on to the next challenge now... building for the 1.8.7-p334 version my colleagues prefer (better compatibility with certain gems). Unfortunately this one was built with with mingw, and my VS2010 build flow that worked for 1.8.6-p287 (mswin) is not successful here. I have the following results:

build against 1.8.7-p334 built from source with VS2010: compile succeeds, load fails with missing dll msvcrt-ruby18-vc100 (or something like that). If I supply the dll, Sketchup crashes.
build against 1.8.7-p334 one-click install (mingw): compile fails. Lots of warnings about win32.h and missing ruby API functions
hybrid build pointing includes to mswin build of 1.8.7-p334, library from mingw one-click: link error

I'm under the impression that because dll's use the C API it should be possible to load a VS2010-generated extension into a mingw-built Ruby. Is it a hopeless cause?

Thanks,
Jeff

jefftrull

Today I made a startling discovery: the plugin I built under VS2010 against the 1.8.6-p287 mswin Ruby will load and run without changes in the 1.8.7-p334 mingw build. So the Ruby version and compiler both mismatch, and yet everything works. I'm dumbfounded but delighted, and my previous question is now moot.

thomthom

thomthom

@thomthom said:

Btw, does anyone know how one can make extconf.rb and make/nmake output their files to a given folder? I'd like to make it so that each platform outputs its generated files to separate directories.

Anyone know how to achieve this?

Making it so that when I build and compile under Windows everything is placed in a "win32" folder and "osx" when using OSX?
Or rather, to clarify, I know how to do conditionals - just don't know how to control where the generated files are output.

Dan Rathbun

and you are compiling from the commandline, not from within the Visual Studio GUI interface, correct ?

thomthom

Currently using nmake that comes with MS VS C++.

And I'm using a extconf.rb with mkfm to generate the makefile.

thomthom

Is it possible to build an Ruby C Extension under Windows that doesn't require additional libraries? When using Visual C++ to build the extensions require the C++ runtime library.

tbd

yes. my old example did that. best is to check the DLL imports section to see what functions it requires

thomthom

@unknownuser said:

yes. my old example did that. best is to check the DLL imports section to see what functions it requires
Ah, the Pelles C project! Is it possible to use to to just compile the C source without creating a project? (just trying to find a solution without creating too many extra project files.)

tbd

@unknownuser said:

Is it possible to use to to just compile the C source without creating a project? (just trying to find a solution without creating too many extra project files

the .ppj file is just a collection of commands. you can easily convert it to a .bat file if you dont want to have extra files (remember to create the .def file for the .dll link)

thomthom

Do you remember the cause of the C:\ruby\src\ruby-1.8.6-p111\missing.h(71): error #1050: Redefinition of macro 'isinf'. error? And can you explain what your workaround actually do?

Trying to set up a project myself so I actually understand this.

thomthom

And why is the macro redefinition just a warning for this guy, but an error in Pelles C?
https://github.com/barrie0482/rrdruby_win32_build/wiki

thomthom

hm... there is an msvcrt-ruby18.dll in the SketchUp folder - can I make my Visual Studio C++ project rely on this instead? So when the C Extension loads under SketchUp Ruby the runtime is there - installed by SketchUp. ??

thomthom

@unknownuser said:

@unknownuser said:

And can you explain what your workaround actually do?

isinf is already defined in PellesC libraries so there is no need to include that file again.

But I am not including it myself - it's an error that comes from the Ruby missing.h file... :S


Building hello_world.obj.
Use <stdlib.h> instead of non-standard <malloc.h>
C;\ruby\src\ruby-1.8.6-p111\missing.h(71); error #1050; Redefinition of macro 'isinf'.
*** Error code; 1 ***
Done.

thomthom

@unknownuser said:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx - the DLL is already loaded by Sketchup so it will use that version.

When compiling with Pelles C, right? Any way to make VC++'s nmake rely on the bundled SketchUp CRT instead of the VSC++ CRT? (splitting my quest into two projects here...)

tbd

@unknownuser said:

And can you explain what your workaround actually do?

isinf is already defined in PellesC libraries so there is no need to include that file again.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx - the DLL is already loaded by Sketchup so it will use that version. also you can copy the msvcrt-ruby18.dll in your dev directory to be picked up when debugging outside Sketchup (which I hope you do, otherwise dev time is slooooow)

tbd

@thomthom said:

But I am not including it myself - it's an error that comes from the Ruby missing.h file... :S

that's why you need to have #define HAVE_ISINF 1 in your code, so that Ruby will not double include

@unknownuser said:

Any way to make VC++'s nmake rely on the bundled SketchUp CRT instead of the VSC++ CRT? (splitting my quest into two projects here...)

compile with the same VC or dont link any CRT and use a replacement static lib (there are some minimal libs on the net)