Wow. That is rather subtle/esoteric. Thanks for chasing that down.
It makes me wonder what use case / platform drove them to even support
the other options -- and to deprecate working functionality.
Looks like I'll stick with MODULE.
Best,
Rob
On Sat, Dec 9, 2017 at 11:46 AM, J. Caleb Wherry
I think you intuition is spot on here, I also think loading a static lib at
runtime is strange. That is why I always build the SWIG libs as shared.
To be honest, I don’t even know why static is an option. I’m sure there is
some case or reason but I wouldn’t ever build it as a static lib.
As for M
Thanks much for your patient and detailed answers -- and sorry for
dropping the mailing list.
It seems very foreign to me to load a static library at runtime -- oh well.
How is 'MODULE' different from 'SHARED' ?
Rob
On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry wrote:
> (Adding the CMake l
(Adding the CMake list back so others can reference it)
FYI: I only use the CMake SWIG macros for Java wrappers so my reference is
for that.
With Java, the Java wrapper SWIG creates does a load library on the library
created from the swig_add_library_call. So at the end of the day, it
doesn’t mat
USE_BUILD_SHARED_LIB literally means use whatever is set by
BUILD_SHARED_LIBS. Typically, this is the preferred method for either
building a static or shared lib since the user can control what they
want/need. You don’t have to specify the type of lib to build when calling
add_library, it uses shar
In version 3.8, SWIG_ADD_MODULE was deprecated in favor of
SWIG_ADD_LIBRARY. This added the ability to control the TYPE for the
target. From the documentation, the options are this:
https://cmake.org/cmake/help/v3.8/module/UseSWIG.html
TYPE
However, I can find no documentation of what these o
