Is there naming convention related configure options in OMPI?
Do you see any objections about --enable-oshmem-xxx or they must be
replaced with --enable-shmem-xxx?
On 17.10.2013 14:20, Jeff Squyres (jsquyres) wrote:
> Mellanox --
> In r29448, you deleted the comment without doing what it explicitly said to do. For example, you can --disable-mpi-fortran --enable-oshmem-fortran and get a broken build.
> Additionally, the shmem example in examples/ has several problems:
> 1. Why all the #defines? This is supposed to be a trivial "hello world in shmem" program, not a test case. Please make it the equivalent of "hello world".
> 2. The hello world shmem program does not follow the same naming conventions as the rest of the code in the examples/ directory.
> 3. There's no Fortran shmem example.
> Adding C/Fortran shmem test cases to a test suite for MTT runs would be a very good thing. Can they be added so that others can run shmem tests in an automated fashion? Indeed, we have no proof of any shmem correctness right now; that makes me quite nervous...
> On Oct 17, 2013, at 1:42 AM, <svn-commit-mailer_at_[hidden]> wrote:
>> Author: miked (Mike Dubman)
>> Date: 2013-10-17 01:42:43 EDT (Thu, 17 Oct 2013)
>> New Revision: 29448
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/29448
>> add --enable-oshmem-fortran opt to configure
>> Text files modified:
>> trunk/config/ompi_configure_options.m4 | 1 -
>> trunk/config/oshmem_configure_options.m4 | 29 ++++++++++++-----------------
>> 2 files changed, 12 insertions(+), 18 deletions(-)
>> Modified: trunk/config/ompi_configure_options.m4
>> --- trunk/config/ompi_configure_options.m4 Thu Oct 17 01:39:20 2013 (r29447)
>> +++ trunk/config/ompi_configure_options.m4 2013-10-17 01:42:43 EDT (Thu, 17 Oct 2013) (r29448)
>> @@ -114,7 +114,6 @@
>> # MPI profiling
>> Modified: trunk/config/oshmem_configure_options.m4
>> --- trunk/config/oshmem_configure_options.m4 Thu Oct 17 01:39:20 2013 (r29447)
>> +++ trunk/config/oshmem_configure_options.m4 2013-10-17 01:42:43 EDT (Thu, 17 Oct 2013) (r29448)
>> @@ -79,26 +79,21 @@
>> AM_CONDITIONAL(OSHMEM_PROFILING, test "$oshmem_profiling_support" = 1)
>> -# Whether to build the OpenShmem fortran support or not For the
>> -# moment, use the same value as was derived from --enable-mpi-fortra.
>> -# *This seems wrong*; someone should somehow unify these two
>> -# options... but the implications are complicated.
>> -# Option 1: make --enable-fortran that governs both MPI and shmem.
>> -# This has 2 implications:
>> -# - --enable-mpi-fortran needs to be maintained for at least the
>> -# 1.7/1.8 series
>> -# - what to do with --enable-mpi-cxx? It should be made consistent --
>> -# so make it --enable-cxx?
>> -# Option 2: make separate --enable-oshmem-fortran. This seems sucky,
>> -# though, because oshmem Fortran depends on a lot of MPI Fortran
>> -# infrastructure. If it isin't there, then oshmem Fortran can't
>> -# built.
>> +# Fortran bindings
>> -# Option 3: ...? (something better than option 1/2?)
>> + [enable OSHMEM Fortran bindings (default: enabled if Fortran compiler found)]))
>> +if test "$enable_oshmem_fortran" != "no"; then
>> + AC_MSG_RESULT([yes])
>> + OSHMEM_WANT_FORTRAN_BINDINGS=1
>> + AC_MSG_RESULT([no])
>> + OSHMEM_WANT_FORTRAN_BINDINGS=0
>> AC_MSG_CHECKING([if want to build SHMEM fortran bindings])
>> [test $OSHMEM_WANT_FORTRAN_BINDINGS -eq 1])
>> AS_IF([test $OSHMEM_WANT_FORTRAN_BINDINGS -eq 1],
>> svn-full mailing list