[bug#27905] changes for openmpi

[ludovic.courtes@inria.fr (Ludovic Courtès)]

Hi Dave,

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 think that's a problem, as people who want to avoid the GUI
> stuff will look for an alternative.
>
>> Also, it shouldn’t make any difference to the closure size of openmpi
>> anyway, no?
>
> No, but I think you should be able to run the hwloc programs on compute
> nodes without requiring X support, and you sometimes need to run openmpi
> programs specifically with openmpi (for memory affinity, for instance).

OK so the gain over the current status (with the “lib” output) is that
people would be able to get, say, ‘hwloc-bind’, without getting the full
‘lstopo’ and its dependencies, right?

I guess that makes sense, though at the same time ‘lstopo’ is probably
the most widely used program in hwloc.  Perhaps we should keep the
current “lib” separation, and instead provide an “hwloc-minimal”
package that does not depend on X11/Cairo?

>> > +         (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?
>
> That would still pull in valgrind, which drags in a lot else (gdb, perl,
> python...).  The support isn't commonly used as far as I can tell, and
> isn't configured by default -- I forgot about the performance hit
> <https://www.open-mpi.org/faq/?category=debugging#memchecker_overhead>.

The hunk above is within Valgrind, so I don’t understand what you mean
by “that would still pull in valgrind.”

My suggestion was to:

  1. Remove Valgrind from the inputs of Open MPI;
  2. Not add the ‘install-openmpi’ phase above to Valgrind.

Does that make sense?

Thank you,
Ludo’.