(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.mcdon...@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 <calebwhe...@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.mcdon...@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
-- 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