Variants for static/shared build types

[citibeth]

@scheibelp @mamelara @tgamblin

This proposal is the result of previous proposals and discussions. The idea is to standardize how packages process static vs. shared builds; and to make it easy and logical to control for the user. Comments welcome.

There will be a multi-valued variant build_type that can take the values static or shared. Packages will interpret the variant as follows. In each case, if the package is incapable of doing the required task, then the value should not be an option for build_type in that package; thus causing an error if the user tries to choose it. The build_type variant should always default to shared.

1. static: The package must produce a static library (preferably without PIC).
2. shared: The package must produce either a shared library, or a static library with PIC. Thus, shared means "appropriate for use in a shared-linking context", not necessarily "produces a shared library."

There will be a second multi-valued variant shared_type that can take the values shared or pic. It is only in effect if build_type=shared. In that case, the package will build true shared libraries if shared_type=shared, and static libraries with PIC if shared_type=pic. It should default to shared, if the package is capable of building true shared libraries. If a package cannot build the requested library type, it should not allow that particular value of the shared_type variant, thus forcing a concretization error.

Some upstream packages have builds that simultaneously generate shared and static libraries. This feature will be ignored by Spack; in fact, Spack packages might choose to delete "extra" libraries not specified by the build_type variant. If a user wants multiple build types, then the package will have to be built and installed twice, with different values for the build_type or shared_type variants.

Use Cases

1. Users will typically set build_type as a "global" variant (Allow setting default variants #2644), depending on whether they want to build with shared or static linking. Users who do shared will do nothing; those who need to build static will set build_type=static in the appropriate YAML config file.

2. For users who have build_type=shared, they can additionally configure certain packages for either true shared libs, or static libs with PIC. It is expected that shared_type will be configured on a per-package basis, as appropriate.

[citibeth]

Also.. CMakePackage could potentially automate some of the required shared/static machinery. But upstream packages would need to not "mess it up" by hard-wiring the build type (I know my upstream packages DO make this mistake).

https://cmake.org/cmake/help/v3.0/variable/BUILD_SHARED_LIBS.html

[davydden]

we already have a discussion on that topic #2380, why create a separate issue?

[citibeth]

Because this is a new try. Thank you for linking to previous tries.

…

On Jan 9, 2017 2:58 AM, "Denis Davydov" ***@***.***> wrote: we already have a discussion on that topic #2380 <#2380>, why create a separate issue? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2779 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1cdyZTQO_QMK9xCNmq7uxL_KHitXgKks5rQeiOgaJpZM4Ld5W4> .

[adamjstewart]

@citibeth We already have over 400 issues in Spack. The more you add, the less likely we are to solve any of them. There is no reason to split the discussion over multiple issues. It just makes it harder to follow. If there is already an open issue on a topic, please refrain from opening another issue.

[citibeth]

Sorry, I disagree. It has admittedly been difficult to find a design for the static/shared issue that suits everyone's needs. This thread is the latest attempt at that. By putting it at the top of a new Issue, it makes it easy for people to give this idea an up-or-down "vote." They should not have to dig through a long-running thread with 5 now-obsolete proposals, before coming upon the "current" proposal 30 comments deep in the thread.

[alalazo]

We already have over 400 issues in Spack

Time flies and we are over 600 now. Trying to burn a few. The most recent discussion on this topic is #5269