[CMake] SWIG_ADD_LIBRARY Documentation?

[J. Caleb Wherry]

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