From: ludovic.courtes@inria.fr (Ludovic Courtès)
To: Dave Love <fx@gnu.org>
Cc: 27905@debbugs.gnu.org
Subject: [bug#27905] changes for openmpi
Date: Mon, 04 Sep 2017 17:10:24 +0200 [thread overview]
Message-ID: <873782xzxb.fsf@inria.fr> (raw)
In-Reply-To: <87d17aznix.fsf@albion.it.manchester.ac.uk> (Dave Love's message of "Fri, 01 Sep 2017 12:06:14 +0100")
[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]
Dave Love <fx@gnu.org> skribis:
> Ludovic Courtès <ludovic.courtes@inria.fr> 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 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/users@lists.open-mpi.org//msg31459.html>.
>
> The wrapper library may still be relevant for mpich-y MPIs, if they get
> used -- I don't know.
OK.
So to me that means we can apply the patch below and be done with it.
Fine with you?
Thanks,
Ludo’.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1269 bytes --]
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
(package
@@ -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)))
(native-inputs
`(("pkg-config" ,pkg-config)
("perl" ,perl)))
@@ -142,8 +140,6 @@ bind processes, and much more.")
;; it reduces the closure size considerably.
"--disable-vt"
- ,(string-append "--with-valgrind="
- (assoc-ref %build-inputs "valgrind"))
,(string-append "--with-hwloc="
(assoc-ref %build-inputs "hwloc")))
#:phases (modify-phases %standard-phases
next prev parent reply other threads:[~2017-09-04 15:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-01 12:54 [bug#27905] changes for openmpi Dave Love
2017-08-21 15:12 ` Ludovic Courtès
2017-08-23 13:00 ` Dave Love
2017-08-31 7:58 ` Ludovic Courtès
2017-09-01 11:24 ` Dave Love
2017-09-01 11:06 ` Dave Love
2017-09-04 15:10 ` Ludovic Courtès [this message]
2017-09-07 16:14 ` Dave Love
2017-09-11 20:24 ` Dave Love
2017-09-12 7:00 ` bug#27905: " Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873782xzxb.fsf@inria.fr \
--to=ludovic.courtes@inria.fr \
--cc=27905@debbugs.gnu.org \
--cc=fx@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).