[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#27905] changes for openmpi
From: |
Dave Love |
Subject: |
[bug#27905] changes for openmpi |
Date: |
Fri, 01 Sep 2017 12:06:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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?
> 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 libmpiwrap.so, 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:
<https://www.mail-archive.com/address@hidden//msg31459.html>.
The wrapper library may still be relevant for mpich-y MPIs, if they get
used -- I don't know.
- [bug#27905] changes for openmpi,
Dave Love <=