Skip to content

Telcon: 2015 07 09

Jump to bottom Edit New page
Todd Gamblin edited this page Jul 9, 2015 · 7 revisions

Participants

  • Todd Gamblin (LLNL)
  • Matt Legendre (LLNL)
  • Chris Chambreau (LLNL)
  • Jim Galarowicz (Krell)
  • Mike Collette (LLNL)

News

  • May be adding Cray support sooner rather than later.
  • Teams are porting to Trinity
  • already have some codes running, but need better packages.

Agenda

Discussion on how we should build on Cray machines:

  1. Detecting compilers * How should the compiler wrappers handle compilers that are available through modules in the Cray PrgEnv?

    • Generalize detection code to find compilers via modules as well as via PATH.
    • Add module field to compiler config; indicates compiler should be loaded by the compiler wrapper before build. * What about compilers that require sourceme.sh scripts?
    • Add a parameter for that too.

  2. How should cross-compiled platforms be handled? * Spack probably needs a general architecture description containing:

    • How to detect that we're on a particular architecture (e.g., look for/bgsys, or analog for Cray)
    • Hints about where to look for compilers
    • Hints about what back-end architectures are available
    • Default environment setting (e.g., Cray wants PKG_CONFIG_PATH)

  3. External package support * Potentially allow external MPI packages to be loaded from modules, like compilers will be. * Autodetection? Build deps?

  4. Whether spack should build for the back-end or front-end by default. * How should spack determine which platform to build packages for? * Packages should probably have a preference

    • e.g.: this package is typically a front-end build (like CMake) * build dependencies likely need to be built for front-end * link dependencies need to be built for back-end if root package is for back-end.
    • Need depends_lib, depends_build

  5. How should spack's generated modules be modified to support Cray's environment? * More robust way to insert things into module files from packages (PATHs, etc.) * additional support needed in the EnvModule and/or TclModule class? * see lib/spack/spack/modules.py

Discussion

External packages

  • Matt has spent an hour or so on this

  • has some sample config file formats for registering externals.

    • Wildcard:

      externals:
  mvapich2%gcc+debug: /usr/local/tools/mpvapich2-gnu-debug-$(VERSION)

    • Wildcard with constraint tree:

      externals:
  mvapich2:
    %gcc:
      +debug: /usr/local/tools/mpvapich2-gnu-debug-$(VERSION)

    • Explicit:

      externals:
  mvapich2%gcc+debug@1.9: /usr/local/tools/mpvapich2-gnu-debug-1.9

  • Todd mentioned issue:

    1. What if mvapich2 is built with hwloc@1.6 but some other tool depends on hwloc?

    • Example spec:

      app
  ^hwloc
  ^mvapich2@1.9%gcc   <-- external
    ^hwloc@1.6       <-- external dependency, but NOT mentioned in config file

    • Without additional constraints from the external, this could end up building the app with hwloc@1.9

    • If hwloc@1.9 is RPATH'd into the app, it will take precedence over the hwloc@1.6 that mvapich2 depends on.

    • inconsistent DAG!

    • You really need to be able to mention that externals themselves have DAG constraints, e.g.:

      mvapich2%gcc+debug@1.9:
  path: /usr/local/tools/mpvapich2-gnu-debug-1.9
  depends: hwloc@1.6

    • Now the hwloc@1.6 constraint will be added to the spec when you build with this particular external.

      • ensures DAG consistency
      • doesn't prevent a user from omitting the constraint, but not much you can do about that.
      • users need to remember that Spack can't make many guarantees about externals.
    1. If you match $(VERSION) wildcards in paths, isn't that a security issue?
    • Someone could stick a malicious lib there and you'd pick it up.
    • Admins probably want explicit deps.
Add a custom footer
Clone this wiki locally