tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Allow 'native' option to mk/mpi.buildlink3.mk to use the system's MPI implementation



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

> Examples for differing MPI and toolchain choices on our system:
>
> PGI compiler with shipped MPI …
>
> $ module switch env env/pgi-19.7_openmpi-3.1.3
> $ mpicc -O -o hello.pgi hello.c
>
> … Intel MPI …
>
> $ module switch env env/cuda-9.0.176_intel-17.0.5_impi
> $ mpicc -O -o hello.intel hello.c 
>
> … GCC, OpenMPI …
>
> $ module switch env env/2020Q3-gcc-openmpi
> $ mpicc -O -o hello.ompi hello.c 
>
> I hope you notice a pattern here;-) There are specific wrappers for
> some implementations and sometimes custom environment variables to
> choose the actual compiler, but the idea is that this just wraps over
> $CC with some custom linker flags. This is a long-established standard.

Thanks.  I am surprised that this is so uniform, and there is no need
for ${MPI_CFLAGS}, ${MPI_LDFALGS} and so on.   That's really what I was
getting at, in terms of treating each possible implementation as at last
a pseudo-package.  But if that's truly not necessary, I can see your
point that it's just extra work.   If that changes, we'll have to do it
later and your change is minor enough.  So it seems ok to me.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index