[CMake] SWIG_ADD_LIBRARY Documentation?

[Rob McDonald]

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 <calebwherry at gmail.com> wrote:
> (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
> matter if it’s a shared or static library, the Java 8 JNI can load it. I
> have no idea how python deals with the library created from this call. But
> if it deals with loading the lib the same as Java, then it doesn’t matter.
>
> For our Java wrappers, I always compile shared libs. And as for mac, SWIG
> has a special convention and names shared libs “name.jnilib”, not the
> standard “name.dylib”.
>
> From a practical standpoint (and my opinion): shared libs are generally
> better since they (usually) have a well defined interface and only include
> the code needed for the lib’s interface. A static lib potentially leaks a
> lot more about your build/files/etc instead of shared libs. Shared libs are
> generally smaller too.
>
> -Caleb
>
> On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <rob.a.mcdonald at gmail.com>
> wrote:
>>
>> Ok, thanks.
>>
>> In the context of a SWIG wrapper, what would happen if I chose STATIC?
>>
>> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --
>> would I then have to re-build Python and statically link that binding
>> in to get it all to work?
>>
>> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).
>>
>> What is the practical difference of these choices?
>>
>> Rob
>>
>>
>>
>>
>> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <calebwherry at gmail.com>
>> wrote:
>> > 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 shared if BUILD_SHARED_LIBS is true, otherwise
>> > static.
>> >
>> > Otherwise you can specify the TYPE and the user can’t override it, they
>> > always get the type of lib you set.
>> >
>> > -Caleb
>> >
>> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <rob.a.mcdonald at gmail.com>
>> > wrote:
>> >>
>> >> 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 <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS>
>> >>
>> >> However, I can find no documentation of what these options mean and
>> >> why someone would choose one over the other.
>> >>
>> >> I found some developer comments in KitWare's bug tracker proposing a
>> >> change of the default, but it looks like they left it as 'MODULE'.
>> >> https://gitlab.kitware.com/cmake/cmake/merge_requests/253
>> >>
>> >> However, even which TYPE value is default appears undocumented.
>> >>
>> >> If we want to generalize from ADD_LIBRARY, we can get an idea of what
>> >> some of the options generally mean:
>> >> https://cmake.org/cmake/help/v3.0/command/add_library.html
>> >>
>> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears
>> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed
>> >> alternate default in the referenced proposal.
>> >>
>> >> So, can anyone explain in the context of SWIG/C++/Python, why I would
>> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would
>> >> be the practical impact on my wrapper, how it is built, its
>> >> dependencies, etc.
>> >>
>> >> Thanks for any help,
>> >>
>> >> Rob
>> >> --
>> >>
>> >> Powered by www.kitware.com
>> >>
>> >> Please keep messages on-topic and check the CMake FAQ at:
>> >> http://www.cmake.org/Wiki/CMake_FAQ
>> >>
>> >> Kitware offers various services to support the CMake community. For
>> >> more
>> >> information on each offering, please visit:
>> >>
>> >> CMake Support: http://cmake.org/cmake/help/support.html
>> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> >>
>> >> Visit other Kitware open-source projects at
>> >> http://www.kitware.com/opensource/opensource.html
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://public.kitware.com/mailman/listinfo/cmake
>> >
>> > --
>> > Sent from my iPhone 4s
>
> --
> Sent from my iPhone 4s