Re: [RFC] gfortran's coarray (library version): configure/build and the testsuite

[Mikael Morin <mikael dot morin at sfr dot fr>]

On Tuesday 05 April 2011 22:01:03 Tobias Burnus wrote:
> Hello,
> 
> Fortran 2008 has a build in parallelization (Coarray [Fortran], CAF)
> [1]. gfortran did the first steps to a communication-library version
> [2]. The library will be based MPI.
> 
> There are two issues I like to discuss in this email:
> 
> a) configuring and building
> b) Test-suite support
> 
> 
> Let's start with (b) which is more important for me. The current scheme
> is that the user somehow compiles the communication library (libcaf) [2]
> and then builds and links doing something like:
>    mpif90 -fcoarray=lib  fortran.f90 -lcaf_mpi
> or alternatively
>    gfortran -fcoarray=lib fortran.f90 -lcaf_mpi
> -I/usr/lib64/mpi/gcc/openmpi/include -L/usr/lib64/mpi/gcc/openmpi/lib64
> -lmpi
> with some -I<dir>, -L<dir> -l<libs> are added. (Cf. "mpif90 -show" of
> some MPI implementations.) The resulting program is then run using, e.g.,
>    mpiexec -n 3 ./a.out
> Alternatively, it could be just "-lcaf_single" which is run like normal
> ("./a.out").
> 
> Thus, one needs some means to add link and compile options - and a means
> to add an (optional) run command. Those one would probably pass via
> environment variables.
As I said in the other mail, I think we should try to test everything that is 
testable without the user requiring it or configuring anything.
We could have a gfortran.dg/caf (like gomp,vect,...) dir in which every test 
is tested against -fcoarray=single and with -fcoarray=lib for every libcaf_*.

> 
> One would then either only run the tests if the environment variable is
> set - or if "libcaf_single.a" is installed by default (cf. below),  one
> could default to linking that version if no environment variable is set.
> Then "make check-gfortran" could then always run the CAF library checks
> - otherwise, only conditionally.
> 
> What do you think? Do you have comments how this should be done? I also
> wouldn't mind if someone could help as I am not really comfortable with
> the test-suite setup nor do I know Lisp well.
All is well, it is TCL, not Lisp. ;-)


> Thus, the first question is: Should one build and install single.c
> (libcaf_single.a) by default? (Might also relate to (a), namely how the
> test suite is handled.)
It is a small library to be put in a gcc-owned (thus it shouldn't be too 
disturbing) directory. So, yes, in my opinion, we can install it by default.
The same goes for libcaf_mpi. Not as small, yet still reasonable.
We should install it if mpi is available.

> 
> And the second question is: Should one be able to configure and build
> mpi.c (libcaf_mpi.a) by some means? I think users interested in could
> also do the procedure of [2] - or let their admin do it. (For Linux
> distributions one would run into the problem that they typically offer
> several MPI implementations, e.g. Open MPI and MPICH2, which couldn't be
> handled that way.)
We should try to have [2] done automatically if possible.
After all, all that is needed is a mpicc in the PATH (and the corresponding 
mpif90 for the testsuite) so the corresponding autoconf code shouldn't be too 
convoluted.

For the multiple MPI implementations, either we accept to choose only one at 
configure time, or we could ship a stripped down mpi.h containing only the 
interfaces we care about. As the interfaces are standard (aren't they?) we 
could link with any standard-compliant implementation afterwards. 
With that, no configury needed, we install unconditianally the libcaf_mpi.a 
file, but some manual tweaking is needed at make check time to choose one mpi 
implementation. Another downside is a burden on us to keep the file up-to-
date.


Mikael