Skip to content

Telcon: 2021 09 01

Jump to bottom Edit New page
Peter Scheibel edited this page Sep 1, 2021 · 19 revisions

Weekly Spack meeting to be held on Wednesday September 1st 9am PST

Attendees

  • Todd Gamblin
  • Peter Scheibel
  • Tamara Dahlgren
  • Massimiliano Culpo
  • Greg Becker
  • Stephanie Dempsey
  • Luke Roskop
  • Chuck Atkins
  • Nick Sly
  • Daniel Howard
  • David DelVento
  • Cameron Rutherford
  • Mark Krentel

Agenda

  • Discussion: Defining a standard for shared and static libs

  • Notes from the meeting on shared/static libs

    • Chuck: while there is a PIC option, why not build all static libs with PIC?
      • Arguably no performance issues with building PIC
      • If all libs are built with PIC, then there is no conflict between the shared and static libs
    • Greg: aren't there packages which only allow building both shared and static?
      • In that case the only for example static and static+shared (not just static)
    • There are packages which will default to link shared so there may be some interested in building only the static libs
      • i.e. if you build shared and static libs, it might be hard to tell a dependent to link against the static libs
    • Mark: the shared/static decision shouldn't propagate to dependencies (not all packages may support just shared or just static)
    • Todd: should the choice of static apply to both the executable and the libraries, or not necessarily constrain both?
      • i.e. for a package that produces both a library and an exe, should the exe link shared when the libraries are built as shared?
    • There is interest in building only the shared or only the static libs, and if the build system builds them both, then the Spack package could remove one or the other for the installation. However, if the package builds executables and libraries, then we wouldn't want to remove the shared libraries if the executable links them
    • Underlying assumption: static+pic libs are interchangeable with shared
      • Is this not true for Dyninst?
      • In a sense while they are interchangeable, each is linked differently, so there may be conflicts at the build system level

  • (Partially covered last week - TBC next week) Discussion: Packages which require multiple build systems: how to handle them?

    • E.g. a package where earlier versions use make and later versions use cmake
    • Some packages will want to use a different build system on Windows
    • Side note: packages are only used at build time
    • ? Do we use when decorators on methods other than to constrain a method to only run for particular versions
    • Adam has created documentation on how to maintain a package which uses different build systems for different versions
    • Todd: use @when decorators on the subclasses
      • Massimiliano: for packages which extend other packages, this would be problematic

  • (Not covered this week - moving to next) Discussion: Packages with multiple conflicting libraries - how to support them?

  • Discussion: long environment activations - are you having an issue with this?

Add a custom footer
Clone this wiki locally