Re: [PATCH] 2015Q2 patches and one outstanding issue with pkgtools/p5-pkgsrc-Dewey

[Aleksej Saushev <asau%inbox.ru@localhost>]

  Hello,

Thomas Orgis <thomas.orgis%uni-hamburg.de@localhost> writes:

> Patch 4: mk-mpi-buildlink3-do-nothing-for-native.patch
>
> This is not a little fixup but a feature patch: Add the option of
>
> MPI_TYPE = native
>
> to use a system-installed MPI library. This I will exclusively use on
> our system from now on, since we install several toolchains with MPI
> included, pkgsrc built on top of that.

Could you, please, in the future reflect such things in subject header?
It took some extra effort in finding your letter. Discussing MPI in a letter
with subject that tells absolutely nothing about even the possibility of it,
is somewhat confusing.

+.if $(MPI_TYPE) == "native"
+# nothing

I don't like this approach. I see following problems with it.

Most likely your "native" implementation is just some other version of
MPICH or OpenMPI. In this case, it is unclear why a package that uses,
say, MPICH suddenly is marked as "native".

It is argued from time to time that we want to support MPI the way we
support, say, Python. That is we want to allow installing several
versions of packages that utilise different MPI implementations.
In this case, you may want for some obvious reasons to use native MPICH
and native OpenMPI. Your "native" is even more confusing then, since
you'll have packages that use MPI_TYPE "mpich" and "openmpi".

Since your native implementation is most likely MPICH or OpenMPI,
your use case is naturally supported by builtin framework.
Using builtin framework helps not only you but future use case of
supporting several MPI frameworks at the same time.

In my opinion, you should rather take the approach of adding builtin
support to OpenMPI and MPICH packages. If you want any help with this,
I'm glad to offer it.


-- 
HE CE3OH...