SWIG_ADD_LIBRARY Documentation?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

SWIG_ADD_LIBRARY Documentation?

Rob McDonald
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
Reply | Threaded
Open this post in threaded view
|

Re: SWIG_ADD_LIBRARY Documentation?

J. Caleb Wherry
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 <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: SWIG_ADD_LIBRARY Documentation?

J. Caleb Wherry
(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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: SWIG_ADD_LIBRARY Documentation?

Rob McDonald
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> 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 <[hidden email]>
>> > 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
Reply | Threaded
Open this post in threaded view
|

Re: SWIG_ADD_LIBRARY Documentation?

J. Caleb Wherry
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> 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 <[hidden email]>
>> > 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
Reply | Threaded
Open this post in threaded view
|

Re: SWIG_ADD_LIBRARY Documentation?

Rob McDonald
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>> 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 <[hidden email]>
>> > 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 <[hidden email]>
>> >> 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
>> >> > <[hidden email]>
>> >> > 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