- Make the F90 bindings compile and link properly with gfortran 4.0,
4.1, Intel 9.0, PGI 6.1, Sun (don't know version offhand -- the most
current as of this writing, I think), and NAG 5.2, although some
have limitations (e.g., NAG can't seem to handle the medium and
large sizes)
- Building the F90 "small" module size is now the default, even for
developers
- Split up mpif.h into multiple files because parts of it were toxic
to the F90 bindings
- Properly specify unsized/unshaped arrays to make the bindings work
on all known compilers
- Make ompi_info show Fortran 90 bindings size
- XML somewhat lags the generated scripts as of this commit, but
functionality was my main goal -- the XML can be updated later (if
at all).
This commit was SVN r10118.
svn merge -r 9453:9609 https://svn.open-mpi.org/svn/ompi/tmp/f90-stuff .
Several improvements over the current F90 MPI bindings:
- The capability to make 4 sizes of the F90 bindings:
- trivial: only the F90-specific MPI functions (sizeof and a few
others)
- small: (this is the default) all MPI functions that do not take
choice buffers
- medium: small + all MPI functions that take one choice buffer
(e.g., MPI_SEND)
- large: all MPI functions, but those that take 2 choice buffers
(e.g., MPI_GATHER) only allow both buffers to be of the same type
- Remove all non-standard MPI types (LOGICAL*x, CHARACTER*x)
- Remove use of selected_*_kind() and only use MPI-defined types
(INTEGER*x, etc.)
- Decrease complexity of the F90 configure and build system
This commit was SVN r9610.
they will match the prototypes in the [styictly-typed] MPI F90
bindings. Specifically, fix up MPI_COMM_SPAWN and
MPI_COMM_SPAWN_MULTIPLE so that the constants MPI_ARGV_NULL,
MPI_ERRCODES_IGNORE, and MPI_ARGVS_NULL can be used in the F90
bindings. Thanks to Michael Kluskens for pointing this out to us.
Some work still remains in the F90 bindings -- we are missing all
places where choice buffers can be of type CHARACTER.
This commit was SVN r9198.
support for Fortran 90 module flags in the wrapper compilers when I
re-wrote them to be less project-specific. Re-add that support and drop
the ugly install in include hack I had done.
This commit was SVN r9003.
- move files out of toplevel include/ and etc/, moving it into the
sub-projects
- rather than including config headers with <project>/include,
have them as <project>
- require all headers to be included with a project prefix, with
the exception of the config headers ({opal,orte,ompi}_config.h
mpi.h, and mpif.h)
This commit was SVN r8985.
It appears that some compilers look in the library paths and others in
the include paths, so just have both available and save ourselves the
trouble.
This commit was SVN r8897.
complete, but stable enough that it will have no impact on general development,
so into the trunk it goes. Changes in this commit include:
- Remove the --with option for disabling MPI-2 onesided support. It
complicated code, and has no real reason for existing
- add a framework osc (OneSided Communication) for encapsulating
all the MPI-2 onesided functionality
- Modify the MPI interface functions for the MPI-2 onesided chapter
to properly call the underlying framework and do the required
error checking
- Created an osc component pt2pt, which is layered over the BML/BTL
for communication (although it also uses the PML for long message
transfers). Currently, all support functions, all communication
functions (Put, Get, Accumulate), and the Fence synchronization
function are implemented. The PWSC active synchronization
functions and Lock/Unlock passive synchronization functions are
still not implemented
This commit was SVN r8836.
confuses the Lahey compiler (because it doesn't want to name a module
mpi_kinds.ompi_module). We shouldn't need this because we're already
touching a sentinel file (mpi_kinds.ompi_module) for make
dependencies; we don't need the compiler-generated module to be named
that.
This commit was SVN r8571.
functions (e.g., MPI_REDUCE). We don't generate the back-end
subroutines for them (because it makes an expontential number of
subroutines, and compilers literally will segv), so we shouldn't
generate the f90 interfaces for them, either. This allows user's MPI
F90 apps to automaitcally fall through to the F77 bindings for these
functions.
This commit was SVN r8094.
AM_INIT_AUTOMAKE, instead of the deprecated version.
* Work around dumbness in modern AC_INIT that requires the version
number to be set at autoconf time (instead of at configure time, as
it was before). Set the version number, minus the subversion r number,
at autoconf time. Override the internal variables to include the r
number (if needed) at configure time. Basically, the right thing
should always happen. The only place it might not is the version
reported as part of configure --help will not have an r number.
* Since AM_INIT_AUTOMAKE taks a list of options, no need to specify
them in all the Makefile.am files.
* Addes support for subdir-objects, meaning that object files are put
in the directory containing source files, even if the Makefile.am is
in another directory. This should start making it feasible to
reduce the number of Makefile.am files we have in the tree, which
will greatly reduce the time to run autogen and configure.
This commit was SVN r7211.
mpi_kinds.ompi_module before the rest which depends on it. Fix suffix
rules, add suffix rule for libtool objects for testing. Fix for VPATH
builds.
This commit was SVN r7048.
- fix the --with-f90-max-array-dim configure switch
- fix configure test to find the supported f90 linker switch to find
fortran modules
- Unbelievably, some versions of sh (cough cough Solaris 9 cough
cough) actually seem to internally perform a "cd" into a
subdirectory when you run "./foo/bar", such that if you try to
source a script in the top-level directory in the bar script (i.e.,
". some_script" in the bar script), it will try to run it in the
"foo" subdirectory, rather than the top-level directory! #$@#$%#$%
So we have to pass in the pwd to the scripts so that they know where
some_script is.
- Reworked much of ompi/mpi/f90/Makefile.am for lots of reasons. See
the internal comments (mostly having to do with dependency stuff --
Libtool does not apparently support F90, so we can only build the
F90 library statically.
This commit was SVN r6993.
