<div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">As for MODULE vs SHARED, here is a good answer: <a href="https://stackoverflow.com/a/4968940">https://stackoverflow.com/a/4968940</a>. 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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">-Caleb</div><br><div class="gmail_quote"><div>On Sat, Dec 9, 2017 at 2:26 PM Rob McDonald <<a href="mailto:rob.a.mcdonald@gmail.com">rob.a.mcdonald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks much for your patient and detailed answers -- and sorry for<br>
dropping the mailing list.<br>
<br>
It seems very foreign to me to load a static library at runtime -- oh well.<br>
<br>
How is 'MODULE' different from 'SHARED' ?<br>
<br>
Rob<br>
<br>
<br>
On Sat, Dec 9, 2017 at 11:08 AM, J. Caleb Wherry <<a href="mailto:calebwherry@gmail.com" target="_blank">calebwherry@gmail.com</a>> wrote:<br>
> (Adding the CMake list back so others can reference it)<br>
><br>
> FYI: I only use the CMake SWIG macros for Java wrappers so my reference is<br>
> for that.<br>
><br>
> With Java, the Java wrapper SWIG creates does a load library on the library<br>
> created from the swig_add_library_call. So at the end of the day, it doesn’t<br>
> matter if it’s a shared or static library, the Java 8 JNI can load it. I<br>
> have no idea how python deals with the library created from this call. But<br>
> if it deals with loading the lib the same as Java, then it doesn’t matter.<br>
><br>
> For our Java wrappers, I always compile shared libs. And as for mac, SWIG<br>
> has a special convention and names shared libs “name.jnilib”, not the<br>
> standard “name.dylib”.<br>
><br>
> From a practical standpoint (and my opinion): shared libs are generally<br>
> better since they (usually) have a well defined interface and only include<br>
> the code needed for the lib’s interface. A static lib potentially leaks a<br>
> lot more about your build/files/etc instead of shared libs. Shared libs are<br>
> generally smaller too.<br>
><br>
> -Caleb<br>
><br>
> On Sat, Dec 9, 2017 at 1:00 PM Rob McDonald <<a href="mailto:rob.a.mcdonald@gmail.com" target="_blank">rob.a.mcdonald@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Ok, thanks.<br>
>><br>
>> In the context of a SWIG wrapper, what would happen if I chose STATIC?<br>
>><br>
>> I assume it would result in 'mystuff.a' instead of 'mystuff.so' --<br>
>> would I then have to re-build Python and statically link that binding<br>
>> in to get it all to work?<br>
>><br>
>> If I chose SHARED, would it result in 'mystuff.dylib' (on a Mac?).<br>
>><br>
>> What is the practical difference of these choices?<br>
>><br>
>> Rob<br>
>><br>
>><br>
>><br>
>><br>
>> On Sat, Dec 9, 2017 at 9:43 AM, J. Caleb Wherry <<a href="mailto:calebwherry@gmail.com" target="_blank">calebwherry@gmail.com</a>><br>
>> wrote:<br>
>> > USE_BUILD_SHARED_LIB literally means use whatever is set by<br>
>> > BUILD_SHARED_LIBS. Typically, this is the preferred method for either<br>
>> > building a static or shared lib since the user can control what they<br>
>> > want/need. You don’t have to specify the type of lib to build when<br>
>> > calling<br>
>> > add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise<br>
>> > static.<br>
>> ><br>
>> > Otherwise you can specify the TYPE and the user can’t override it, they<br>
>> > always get the type of lib you set.<br>
>> ><br>
>> > -Caleb<br>
>> ><br>
>> > On Sat, Dec 9, 2017 at 12:23 PM Rob McDonald <<a href="mailto:rob.a.mcdonald@gmail.com" target="_blank">rob.a.mcdonald@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> In version 3.8, SWIG_ADD_MODULE was deprecated in favor of<br>
>> >> SWIG_ADD_LIBRARY.  This added the ability to control the TYPE for the<br>
>> >> target.  From the documentation, the options are this:<br>
>> >><br>
>> >> <a href="https://cmake.org/cmake/help/v3.8/module/UseSWIG.html" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/v3.8/module/UseSWIG.html</a><br>
>> >><br>
>> >> TYPE <SHARED|MODULE|STATIC|USE_BUILD_SHARED_LIBS><br>
>> >><br>
>> >> However, I can find no documentation of what these options mean and<br>
>> >> why someone would choose one over the other.<br>
>> >><br>
>> >> I found some developer comments in KitWare's bug tracker proposing a<br>
>> >> change of the default, but it looks like they left it as 'MODULE'.<br>
>> >> <a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/253" rel="noreferrer" target="_blank">https://gitlab.kitware.com/cmake/cmake/merge_requests/253</a><br>
>> >><br>
>> >> However, even which TYPE value is default appears undocumented.<br>
>> >><br>
>> >> If we want to generalize from ADD_LIBRARY, we can get an idea of what<br>
>> >> some of the options generally mean:<br>
>> >> <a href="https://cmake.org/cmake/help/v3.0/command/add_library.html" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/v3.0/command/add_library.html</a><br>
>> >><br>
>> >> However, that says nothing for USE_BUILD_SHARED_LIBS -- which appears<br>
>> >> to be entirely unique to SWIG_ADD_LIBRARY.  It was also the proposed<br>
>> >> alternate default in the referenced proposal.<br>
>> >><br>
>> >> So, can anyone explain in the context of SWIG/C++/Python, why I would<br>
>> >> want to choose SHARED, STATIC, or USE_BUILD_SHARED_LIBS?  What would<br>
>> >> be the practical impact on my wrapper, how it is built, its<br>
>> >> dependencies, etc.<br>
>> >><br>
>> >> Thanks for any help,<br>
>> >><br>
>> >> Rob<br>
>> >> --<br>
>> >><br>
>> >> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>> >><br>
>> >> Please keep messages on-topic and check the CMake FAQ at:<br>
>> >> <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
>> >><br>
>> >> Kitware offers various services to support the CMake community. For<br>
>> >> more<br>
>> >> information on each offering, please visit:<br>
>> >><br>
>> >> CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
>> >> CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
>> >> CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
>> >><br>
>> >> Visit other Kitware open-source projects at<br>
>> >> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>> >><br>
>> >> Follow this link to subscribe/unsubscribe:<br>
>> >> <a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/cmake</a><br>
>> ><br>
>> > --<br>
>> > Sent from my iPhone 4s<br>
><br>
> --<br>
> Sent from my iPhone 4s<br>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">Sent from my iPhone 4s</div>