[CMake] SWIG_ADD_LIBRARY Documentation?

[Rob McDonald]

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 <calebwherry at gmail.com> wrote:
> 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 MODULE vs SHARED, here is a good answer:
> https://stackoverflow.com/a/4968940. As the comments point out, it isn’t
> obvious or documented what platforms this is actually for. On windows, you
> get the same dll when you specify either.
>
> If all the SWIG wrappers load the libraries dynamically (which glancing at
> the examples it looks like they do), MODULE is more fitting. However since I
> can’t find much on what platforms actually support this I don’t see the
> point in using it over SHARED.
>
> -Caleb
>
> On Sat, Dec 9, 2017 at 2:26 PM Rob McDonald <rob.a.mcdonald at gmail.com>
> wrote:
>>
>> 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
>
> --
> Sent from my iPhone 4s