1
1
Граф коммитов

5 Коммитов

Автор SHA1 Сообщение Дата
Nathan Hjelm
c6e586a81d MPI-3: fortran support for large counts using derived datatypes
Jeff:
 - Make sure not to go over 72 characters.  Love Fortran!
 - Ensure to include 'mpif-config.h' in Type_size_x.

This commit was SVN r28933.
2013-07-23 15:36:03 +00:00
Jeff Squyres
7136dbb5b3 Fixes trac:3523. Discussed on the OMPI weekely teleconf today: add a
configure test to ensure that the Fortran compiler supports BIND(C)
with LOGICAL parameters (per
http://lists.mpi-forum.org/mpi-comments/2013/02/0076.php).

This may become moot shortly -- Pathscale tells me that they intend
upgrade their compiler to support BIND(C) with default LOGICAL in the
very near term (this week?).  But we still want this configure test so
that Open MPI won't even try to build the F08 bindings with older
versions of the Pathscale compilers (or any compiler that doesn't
support BIND(C) and LOGICAL parameters).

This commit was SVN r28110.

The following Trac tickets were found above:
  Ticket 3523 --> https://svn.open-mpi.org/trac/ompi/ticket/3523
2013-02-26 17:11:11 +00:00
Jeff Squyres
d65194a97d Fixes trac:3442: ensure that we don't call "basename" on an empty string.
cmr:v1.7

This commit was SVN r27925.

The following Trac tickets were found above:
  Ticket 3442 --> https://svn.open-mpi.org/trac/ompi/ticket/3442
2013-01-26 14:46:08 +00:00
Jeff Squyres
6d3f566f11 This PUSH is never POP'ed. And we don't want this variable to
disappear, anyway.

This commit was SVN r27913.
2013-01-25 22:15:11 +00:00
Jeff Squyres
b29b852281 Consolidate all the opal/orte/ompi .m4 files back to the top-level
config/ directory.  We split them apart a while ago in the hopes that
it would simplify things, but it didn't really (e.g., because there
were still some ompi/opal .m4 files in the top-level config/
directory, resulting in developer confusion where any given m4 macro
was defined).

So this commit consolidates them back into the top-level directory for
simplicity.  

There's still (at least) two changes that would be nice to make:

 1. Split any generated .m4 file (e.g., autogen-generated .m4 files)
    into a separate directory somewhere so that a top-level -Iconfig/
    will only get our explicitly defined macros, not the autogen stuff
    (e.g., with libevent2019 needing to get the visibility macro, but
    NOT all the autogen-generated inclusion of component configure.m4
    files).
 1. Change configure to be of the form:
{{{
# ...a small amount of preamble/setup...
OPAL_SETUP
m4_ifdef([project_orte], [ORTE_SETUP])
m4_ifdef([project_ompi], [OMPI_SETUP])
# ...a small amount of finishing stuff...
}}}

I doubt we'll ever get anything as clean as that, but that would be
the goal to shoot for.

This commit was SVN r27704.
2012-12-19 00:00:36 +00:00