C++ using swig

tt_su

Additionally I am experiencing a link error when trying to build SUEX_HelloWorld and SUEX_UsingSWIG
I'm guessing that the compiler can't find the SDK.

You don't need SWIG to make a Ruby C/C++ Extensions. If you just want to use the C API licensing features you just need the basics of what SUEX_HelloWorld demonstrate and then add the C API headers and libs to the project.

jolran

Like Thomthom said.

If you look at this topic (same as link above) there is a lot of information for setting up things.

TT guides me through the ordeal in a usual friendly way.

http://sketchucation.com/forums/viewtopic.php?f=180%26amp;t=58825

Also (to my liking) switching to a newer Visual Studio gave better compability with C++ 11
making it easier to work with vectors for ex. I highly recommend doing that.

Garry K

I fixed the link error and have SUEX_HelloWorld working.
I also have WritingToAskpFile working.

skp_to_xml and xml_to_skp do not compile. They require afx.h and afxole.h which did not ship with Visual C++ 2010 express.

I haven't tried licensed_ruby_extension nor TextureMapping

Jolran - thanks for the tip about the compiler and I will read your link. I'm going to need to play with the XCode compiler as well. So far I haven't found out what the costs will be.

There is a visual studio 2012 express but I don't see a link from microsoft for visual c++ 2011 express.

thomthom

Don't think there was a C++ 2011. There was 2010 and 2013.

Garry, was the skp_to_xml example set up to AFX? Don't think it would need that. Lemme look that up when I get into the office.

Garry K

The stdafx.h file contains

#include <SDKDDKVer.h>
#include <afx.h>
#include <afxole.h>

thomthom

So, I asked how that example was made, and it uses MFC for the option dialogs, meaning you cannot use the Express edition to compile it.

The Visual Studio 2013 Community edition would let you compile if you upgraded the project - but then it would not run inside of SketchUp because of runtime clashes.
http://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

Garry K

I've got an XE4 C++ compiler working with slapi.dll for windows X86 but so far only with WritingToAskpFile source code.

The key bit was to create an XE4 compatible lib file by running implib.exe with the correct calling convention. Implib.exe comes packaged with XE4.

implib.exe -a slapi.lib slapi.dll
The -a is for cdecl calling convention which is MS default
I will try with the X64 and see what it takes for Mac OSX versions

There are a number of advantages at least for me to use XE4

The XE4 compiler compiles windows 32 + 64 bit and OSX
There shouldn't be runtime clashes because XE4 uses different libraries
I have years of borland c and c++ source code
Hopefully no need to have xcode compiler

I know this is still very preliminary - but I am excited by the possibilities

Garry K

I also have it compiling win32 code in C++Builder 6 - but I did use the XE4 implib.exe

Instead of using all runtime libraries you can compile a self contained exe - quite a bit larger. Then all you need is borlands memory manager as a runtime.

thomthom

I'm currently building my Visual Studio builds with /MT instead of /MD - to prevent the need to install the crts - since I build with VS2013's dev chain instead of the 2010 which SU currently use.

Garry K

I'm just currently playing around to see how far I can take this. Even though I'm licensed with XE4 I prefer the ease of use of C++Builder 6.

I can successfully import libraries from SU8, SU2013, SU2014 and SU2015
The sample code to write an skp file works with SU2013, SU2014 and SU2015 but not SU8

It appears the library is significantly smaller for SU8, therefore there must be a lot missing.
I'm thinking that it might be time to drop SU7 and SU8

I can remove lots of libraries from CBuilder by simply unchecking things. I can also build microsoft compatible DLL's if needed (change the calling convention)

I've only been playing around with interfacing with SU for the last 3 days. I should have a handle on it by early next week.

Now for Swig and C++Builder 6

thomthom

For my own extensions that I write now I usually drop support for anything older than SU2014 - due to Ruby 2.0 and other improvements since then.