Building smtk statically breaks session registry.

[robertmaynard]

I think we should disable the option to build smtkCore statically. When we do so it causes each session plugin to embed its own version of the session registry, causing global registration of sessions to not work.

[vibraphone]

I don't know that a static smtkCore is avoidable if we ever have to deploy to HPC machines like Crays. So I would rather solve this some other way. Is this urgent/causing trouble for someone?

[robertmaynard]

If we need to support static builds, we would need to teach smtk and cmb that when building statically all session plugins ( discrete, remus, etc ) should be built statically and linked at compile time rather than runtime. Otherwise we get 'problems'.

This issue was discovered when linking to a static moab, as it pollutes the smtk CMake variable space, and partially disabled BUILD_SHARED_LIBS causing havoc. I also noticed that we default to building static instead of shared which also seems to be a bad idea with the above known issue.

[vibraphone]

I am all for changing the default from static to dynamic and fixing MOAB to play well with others. I am not all for abandoning static libraries. But unless fixing MOAB (which seems to have a habit of doing evil in the eyes of CMake) is nigh impossible, I would delay the whole static plugin thing.

[robertmaynard]

Okay I will open a PR that defaults to shared, and defends against the 'evils' of the MOAB CMake code.

[vibraphone]

Okay I will open a PR that defaults to shared, and defends against the 'evils' of the MOAB CMake code.

+1

[robertmaynard]

MR: #346