Aleksej Saushev <asau%inbox.ru@localhost> writes: > 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. > 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. I agree with this approach. Almost everything in mk/foo.mk is about choosing from multiple implementions, each of which is in pkgsrc, and some of which have builtin.mk support. I don't see any reason mpi should be different and I suspect the reason it's not done yet is just lack of motivation (to write builtin to save the extra copy).
Attachment:
pgplcdeniQ3Yq.pgp
Description: PGP signature