Telcon: 2017 08 31
becker33 edited this page Sep 1, 2017
·
9 revisions
- Greg Becker
- Greg Lee
- Mario Melara
- Mark Miller
- Peter Scheibel
- Ben Boeckel
- Steve
-
Changing meaning of extra_rpaths entry #5211
- Links the library as well as adding rpath
-
Dennis Davydov added option to add maintainers to a package
- Allows people to be mentioned when we change a package
- Subject matter experts and users with specific use cases
- Subject matter experts can identify whether bugs are from Spack or upstream
- Short list of code reviewers for changes to the package
- Global and common variants.
- We have had several discussions on this in the past.
- And PRs to partially address it
- https://github.com/LLNL/spack/pull/4797 (merged)
- https://github.com/LLNL/spack/pull/391 (closed)
- https://github.com/LLNL/spack/pull/4969 (merged)
- We have never reached a fully satisfying conclusions.
- I don't think we'll get there in one week
- I think it's time to bring this back into mind
- Why not add global variants?
- We don't want to add nonsensical variants anywhere
- If we can scope them properly (as in #4797, we should do so)
- Where we can't, let's establish conventions.
- Conventions do no good if we don't document them properly (i.e. not just in github comments)
- Use Cases
- Installing a full suite of software with shared potential variants
- Cannot be scoped by build system
- Static vs Shared
- Make packages that support static do so in a common way
- We need a convention for this -- a convention should be specific.
-
~sharedmeans "build static but not shared" -
+sharedmeans "build both static and shared libraries" - Some conversation about changing this convention:
- libraries=shared|static|all
-
- How do we handle PIC with static libraries?
- Installing a full suite of software with shared potential variants
- Greg will propose concrete conventions in github issue this week