<div><div dir="auto">(Adding the CMake list back so others can reference it)</div><div dir="auto"><br></div><div dir="auto">FYI: I only use the CMake SWIG macros for Java wrappers so my reference is for that.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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”.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">-Caleb</div><br><div class="gmail_quote"><div>On Sat, Dec 9, 2017 at 1:00 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">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>> 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 calling<br>
> add_library, it uses shared if BUILD_SHARED_LIBS is true, otherwise 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 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>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">Sent from my iPhone 4s</div>