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
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/