[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#27905] changes for openmpi

From: Ludovic Courtès
Subject: [bug#27905] changes for openmpi
Date: Mon, 04 Sep 2017 17:10:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Dave Love <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>>> * mpi.scm (hwloc)[outputs]: Replace lib with nogui.
>>> (hwloc)[arguments]: Change configure --prefix; use "nogui" output,
>>> not "lib"; populate "all" output.
>>> (openmpi)[inputs]: Use hwloc-nogui.
>> The downside of this is that the “nogui” output is less discoverable
>> (and it’s another user-visible breakage.)
> I don't understand why it's worse than currently.  "hwloc" will provide
> the same as before, won't it?  I guess developer breakage could be fixed
> by retaining the lib output if it matters.
> Maybe it's helpful to try to document what sort of stability is expected
> currently?

Concretely, I have a bunch of packages for linear algebra software
developed at work.  When we add/remove an output to hwloc, those
packages may fail to build (for instance, currently they expect the
“lib” output of hwloc.)

Likewise, “guix package -u” doesn’t deal with output changes (we do have
a mechanism to deal with package renames, but not with output changes.)

>> Also, it shouldn’t make any difference to the closure size of openmpi
>> anyway, no?
> Right.  It wasn't for openmpi specifically.
>>> +         (add-after 'install 'install-openmpi
>>> +           (lambda* (#:key outputs #:allow-other-keys)
>>> +             (let ((dest (format #f "~a/lib/valgrind"
>>> +                                 (assoc-ref outputs "openmpi"))))
>>> +               (mkdir-p dest)
>>> +               (zero?
>>> +                (system (format #f "mv ~a/lib/valgrind/libmpiwrap* ~a"
>>> +                                (assoc-ref outputs "out") dest)))))))))
>> Why move it to a separate output?  After all, we can keep it in “out”
>> since all it costs is the size of, right?
>> Also, I assume that this is functionally equivalent to Open MPI’s
>> built-in Valgrind support, is it?
> This is probably moot.  It isn't entirely equivalent but, more
> importantly, the builtin support apparently doesn't have the performance
> hit which was documented; I haven't checked experimentally.  See this
> thread, though not all my questions were answered:
> <>.
> The wrapper library may still be relevant for mpich-y MPIs, if they get
> used -- I don't know.


So to me that means we can apply the patch below and be done with it.
Fine with you?


diff --git a/gnu/packages/mpi.scm b/gnu/packages/mpi.scm
index 93157e269..ded9d4fda 100644
--- a/gnu/packages/mpi.scm
+++ b/gnu/packages/mpi.scm
@@ -36,8 +36,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages perl)
   #:use-module (gnu packages ncurses)
-  #:use-module (gnu packages pkg-config)
-  #:use-module (gnu packages valgrind))
+  #:use-module (gnu packages pkg-config))
 (define-public hwloc
@@ -126,8 +125,7 @@ bind processes, and much more.")
      `(("hwloc" ,hwloc "lib")
        ("gfortran" ,gfortran)
        ("libfabric" ,libfabric)
-       ("rdma-core" ,rdma-core)
-       ("valgrind" ,valgrind)))
+       ("rdma-core" ,rdma-core)))
      `(("pkg-config" ,pkg-config)
        ("perl" ,perl)))
@@ -142,8 +140,6 @@ bind processes, and much more.")
                            ;; it reduces the closure size considerably.
-                           ,(string-append "--with-valgrind="
-                                           (assoc-ref %build-inputs 
                            ,(string-append "--with-hwloc="
                                            (assoc-ref %build-inputs "hwloc")))
        #:phases (modify-phases %standard-phases

reply via email to

[Prev in Thread] Current Thread [Next in Thread]