[ITK-dev] Not linking against libpython

[Brad King]

On 03/24/2016 10:16 AM, Bradly Lowekamp wrote:
> 1) There could be a target property corresponding to if undefined
>    symbols are allowed. It would be true for this case of linux,
>    where it defaults to allowing undefined symbols. Conversely
>    OSX does not allow undefined symbols by default but has a
>    flag to enable them.

This sounds like a target property one would set to say that the
target is allowed to have undefined symbols when linking.  CMake
would map this to flags or the behavior in (2) below as needed.

> 2) There could be an additional target_link_library keyword to
>    specify the type of linking, say “WEAK”. This could cause a
>    SHARED or MODULE target to to be linked against this library
>    if undefined symbols are NOT allowed.

One may be able to encode that request through a new generator
expression.

I think the above two behaviors may be useful in the long run but
first we should gain experience with it across all platforms in
ITK before trying to design an abstraction for CMake.

> 3) This is the first case I have seen where a MODULE library target,
>    as in one intended to be dynamically loaded, should be handled differently.

FYI the distinction between SHARED and MODULE was originally from
old OS X versions where they were actually different.  Now the
difference is primarily that MODULE libraries cannot be linked to
by other binaries purely by CMake-enforced convention.

> Do you know of a try_compile example which creates a shared library? 

One can use the whole-tree signature of try_compile instead of the
source-file signature.  That allows one to provide the entire
CMakeLists.txt file.

-Brad K