sketchup / ruby-c-extension-examples Goto Github PK

I noticed that the include directory for Release/Debug (2.2) win32 and x64 point to 2.0 Ruby folder . Should it be pointing to 2.2 folder instead?

Also I am receiving the following error in VS2015 with when compiling using /MT in Release (2.2) x64:
c:\ruby-c-extension-examples\thirdparty\include\ruby\2.2\win32_x64\ruby/missing.h(76): error C2375: 'acosh': redefinition; different linkage

C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\math.h(477): note: see declaration of 'acosh'

Within this configuration for Release 2.2 in Linker > Input > Dependencies it links x64-msvcrt-ruby200.lib instead of x64-msvcrt-ruby220.lib. Is it possible that the 220 lib has been compiled with /MD instead of /MT?

Thanks,
Anthony

The Hello World is a silly and meaningless example.

Add some examples with substance. Something that at least looks up some SketchUp model properties and displays them.

I am not completely sure if this actually is a problem, but the 2.2 mac lib has a folder structure that has a few hundred files in it while the older versions (2.0, 1.8) don't have that. Just checking if these are really needed.

I use VS2019 build the 'HelloWorld' project and require .so file in ruby console by one line code：

require 'F:/Data/ruby-c-extension-examples-main/Release (2.2)/x64/SUEX_HelloWorld.so'

But I get an error:

Error: #<LoadError: 126: \x{D5D2}\x{B2BB}\x{B5BD}\x{D6B8}\x{B6A8}\x{B5C4}\x{C4A3}\x{BFE9}\x{A1A3}   - F:/Data/ruby-c-extension-examples-main/Release (2.2)/x64/SUEX_HelloWorld.so>
E:/SketchUp/Tools/RubyStdLib/rubygems/core_ext/kernel_require.rb:92:in `require'
E:/SketchUp/Tools/RubyStdLib/rubygems/core_ext/kernel_require.rb:92:in `require'
<main>:in `<main>'
SketchUp:in `eval'

My friend use the same way to build it and work well.His SUP version is 2018,so I wonder if this project is still valid in SUP2021.

https://github.com/SketchUp/ruby-c-extension-examples/wiki/Adding-SLAPI-to-Visual-Studio

The whole example needs updating, to reflect the name change of the C API dlls.

The naming x64-msvcrt-rubyMm0 (major, minor) has been around for quite a while, and was based on publicly available Ruby builds.

Ruby 3.1 is now publicly available only as an MSYS2 ucrt64 build, with file names x64-ucrt-ruby310. Current Ruby mswin builds are named x64-vcruntime140-ruby310.

So, is it time to name the Ruby files to match stand-alone Ruby builds, and use the mswin name?

Some background:

Recently in the SU forum there was thread mentioning issues with extension gems. I believe they were building with a mingw Ruby 2.7.

I thought I'd see if I could repo it, and started with stand-alone master builds (I built a custom mswin with ucrt naming). After a bit of work, I noticed that the functions in x64-vcruntime140-ruby310.dll do not match the functions in x64-ucrt-ruby310.dll. So, even though Ruby mswin & ucrt builds use the same runtime, they are not the same.

Off-topic:

Ruby 3.1 will build with VS 2022, but it fails some numeric tests. It does build with VS 2019. The bug in 2022 is fixed, but hasn't been released. If you want more info, I can look things up. Ruby master is currently patching around the bug, but since it's assumed it will be fixed/released, the changes haven't been backported...

The Ruby mswin builds used for CI are using Microsoft/vcpkg for libffi, libyaml, openssl, readline, and zlib. Note that the current package OpenSSL version is 'OpenSSL 3.0.5 5 Jul 2022'.

Finally, a stand-alone mswin version of 3.1.2 is available as a release asset in MSP-Greg/ruby-mswin. For several years I have maintained ruby-loco, which has mingw, ucrt, and mswin builds of Ruby master/head. I decided to create ruby-mswin to buld/test/save mswin Ruby release builds, since they aren't available anywhere. RubyInstaller2 only has mingw (ruby 2.4 thru 3.0) and ucrt (Ruby 3.1 and later).

I checked out dev/arm64 and tried to build the project and got this error

ld: warning: ignoring file /Users/dalemartens/mind.sight.studios Dropbox/Dale Martens/Plugins/ruby-c-extension-examples/ThirdParty/lib/mac/2.7-universal/Ruby.framework/Ruby, building for macOS-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x56 0x65 0x72 0x73 0x69 0x6F 0x6E 0x73 0x2F 0x43 0x75 0x72 0x72 0x65 0x6E 0x74 )

Running MacOS 12.1 and Xcode 13.2.1 on an M1 Mac mini

Using VS Express 2015 for Windows Desktop.

I had to change the Runtime Library to use the /MD option instead of the /MT option in order to build SUEXT_HelloWorld for Release (2.0) on the x64 Platform.

Properties > C/C++ > Code Generation >Runtime Library

incompatible library version - SUEX_HelloWorld_2017/SUEX_HelloWorld.bundle

Xcode Version 8.2.1 (8C1002)
ruby-c-extension-examples master
SDK_Mac_17-0-18898

add SketchUpAPI.framework to project , build 。 sketch 2017 pro ruby console，require 。

got “incompatible library version ” error

Hi,
I'm trying to get this HelloWorld project for SketchUp running with win7 with VS 2015 and SU2016 - I t I do it would try it without "SWING"
without success...
I'm missing the ruby code or extension; that would run .so file, and did not manage to make it based on the SketchUp extension su_create_layout_file...

the same problem the other way around:
**I've written a C program which runs good as an exe, and would like to create a Sketchup Extension from it... I've tried to start with the github HelloWorld project, but did not manage to create the appropriate rb file to get it work... I recieve an error message:

Error: 193: %1 ist keine zulässige Win32-Anwendung. - path of .so file
which means "is no valid" Win-32 application....

what did I do wrong?**

Could you give me any clue please...
Thanks in advance!

see also:
https://forums.sketchup.com/t/problem-on-c-ruby-extension/31386/3

Either update the binaries or provide better details on how to consume.

Ref: https://forums.sketchup.com/t/su2019-requires-multiple-binaries/169454/11

Hi,

The contact part of the developer site was giving me a 404 and I can't find anything on the docs nor in the examples in this repo to provide an answer to this.

I want to create an extension which uses the (inverted) z depth/z channel of the user's sketchup model. This tweet was my inspiration:

https://twitter.com/hardmaru/status/1601513412575793155

I'm wondering how I can extract this data in SketchUp? If you could give me any pointers I would be very grateful.

Thank you in advance!

It seems that version won't build with VS 2015.

For the 64 bit versions, you modified the config.h file from the Ruby includes by commenting out the requirement for a specific compiler version by commenting out this:

#if _MSC_VER != 1600
#error MSC version unmatch: _MSC_VER: 1600 is expected.
#endif

The 32 bit include still has this and compilation with Visual Studio 2015 therefore fails.

The swig binary stored at https://github.com/SketchUp/ruby-c-extension-examples/blob/main/ThirdParty/bin/win32/swig/swig.exe has version number 2.0 which is not C++17 compliant.

SWIG documentation indicates that version 4.0 is required to produce C++17 code: https://www.swig.org/Doc4.1/CPlusPlus17.html#CPlusPlus17

Hi:
I download the 2017 SketchupAPI SDK and LayOutAPI SDK, I use RubyExampleCreateLayOut sample,but create .so file can't work on Sketchup2017. But I use MacOS, the same project work well.

I test the code:
this code not work,if I use LOInitialize;

 VALUE create_layout_doc(VALUE self, VALUE skp_path) {
      LOInitialize();
      return Qtrue;
}

But this code not work:

 VALUE create_layout_doc(VALUE self, VALUE skp_path) {
      return Qtrue;
}

I had the following warning at extension startup using ruby 3.2 + swig 4.0:

[path/to/*.so]: warning: undefining the allocator of T_DATA class swig_runtime_data

Found this fix that worked for me (at least it removed the warning)

https://fuchsia.googlesource.com/third_party/swig/+/962f0900018ecb10287b327d261e424fa5ccb755

in case the above is the proper fix...

QUESTION (C function aliasing)

REF: "src/RubyUtils/RubyUtils.h"

Can GetRubyInterface() be aliased? It is quite a long function name (16 chars) and will serve to make code noisier.

How about something shorter that indicates a conversion to VALUE ?
Ideas in order of preference:

• VAL()
• val()
• value()
• C2VAL()