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