[CMake] SWIG_ADD_LIBRARY Documentation?

Sat Dec 9 14:46:48 EST 2017

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20171209/701cfc26/attachment.html>