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