This merges the branch containing the revamped build system based around converting autogen from a bash script to a Perl program. Jeff has provided emails explaining the features contained in the change.
Please note that configure requirements on components HAVE CHANGED. For example. a configure.params file is no longer required in each component directory. See Jeff's emails for an explanation.
This commit was SVN r23764.
note in VERSION file.
NOTE: the versions will ''always'' be 0:0:0 on the SVN trunk and
developer branches. They will only have meaningful values (starting
with 0:0:0 in 1.3.4) on release branches. Only RM's will modify these
values immediately preceeding a release.
This commit was SVN r21729.
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogenhttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponenthttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
are properly linked against libmpi.la.
This required a little creative AM usage, inspired by discussion on
OMPI devel list:
* Make a new ompi/mpi/f77/Makefile_f77base.include; effectively move
the building of the f77 "base" glue stuff (libmpi_f77base.la) into
this Makefile and away from ompi/mpi/f77/Makefile.am. The sources
in question require some specific CPPFLAGS, so we couldn't just add
the raw sources into libmpi_la_SOURCES, unfortunately.
* Include this new Makefile in the top-level ompi/Makefile.am
* The libmpi_f77base.la LT convenience library was already sucked
into libmpi.la; breaking it out into its own Makefile allows us
to build it earlier and therefore complete buidling libmpi.la
earlier.
* Side effect: the ompi/mpi/Makefile.am is now mostly unnecessary; it
no longer specifies a SUBDIRS for each of the bindings directories
to traverse into (since they are now in the top-level SUBDIRS). As
such, the man pages are now also now included in the top-level
ompi/Makefile.am.
The end of the result is that libmpi.la -- including a few sources
from mpi/f77 -- is fully built before the C++, F77, and F90 bindings
are built. Therefore, the C++, F77, and F90 bindings libraries can
all link against libmpi.la.
This commit was SVN r19040.
The following Trac tickets were found above:
Ticket 1409 --> https://svn.open-mpi.org/trac/ompi/ticket/1409
This commit brings over all the work from the /tmp-public/datarep
branch. See commits r16855, r16859, r16860 for the highlights of what
was done.
This commit was SVN r16891.
The following SVN revisions from the original message are invalid or
inconsistent and therefore were not cross-referenced:
r16855
r16859
r16860
The following Trac tickets were found above:
Ticket 1029 --> https://svn.open-mpi.org/trac/ompi/ticket/1029
* Consolidate everything inside of the same AM_CONDITIONAL that is
used to suck in the glue convenience library in ompi/Makefile.am:
OMPI_WANT_F77_BINDINGS. This AM conditional is set to true if we
want (and can support) the F77 MPI API bindings at all (And does
not say anything about whether we are compiling the top-level or
bottom-level f77 directory to get the bindings).
* Clarify all the comments surrounding the [confusing!] issue.
* The problem with r11563 was that it used the wrong AM_CONDITIONAL
to decide whether to build the separate F77 library or not; it
would do so only if the top-level library was being built (e.g., on
systems like OSX where weak symbols don't work the way we need them
to). This patch somewhat simplifies the situation by encapsulating
everything in one large conditional (OMPI_WANT_F77_BINDINGS, as
described above). Hence, libmpi_f77 will exist (and be installed)
if F77 support is enabled overall, regardless of whether you're on
a system with insufficient weak symbol support (e.g., OSX) or not
(e.g., Linux).
This commit was SVN r11618.
The following SVN revision numbers were found above:
r11563 --> open-mpi/ompi@c8f3ff71b1
- ensure to initialize the values that we use for fortran constants
(even tough their *values* don't matter -- only their *addresses* do,
but initializing them or not has implications for the OSX linker)
- move the fortran constants to a file with functions in it, because
the OSX linker sometimes does not import global variables from
object files that do not have functions (I'm not even going to
pretend to get all the subtle details about the OSX linker right
here -- it's just "better" to have global variables in object files
with functions that otherwise get pulled in during linker
resolution).
This commit was SVN r10908.
was that declaring the type of MPI_WTICK and MPI_TIME in mpif-common.h
would allow the F90 bindings to call through to the back end f77
function and have the right return type. But upon reflection, that's
silly -- we were just declaring the variables MPI_WTICK and MPI_WTIME
that were of type double precision. Duh.
So add some fixed (non-generated) wrapper F90 functions to call the
back-end *C* MPI_WTICK and MPI_TIME functions (vs. the back end *F77*
functions). We have to call the back-end C functions because there's
a name conflict if we try to call the back-end F77 functions -- for
the same reasons that we can't "implicitly" define MPI_WTIME and
MPI_WTICK in the f90 module, we can't call such an implicitly-defined
function. So we had to add new back-end C functions that are directly
callable from Fortran, the easiest implementation of which was to
provide 4 one-line functions for each (rather than muck around with
weak symbols).
This commit was SVN r10448.
add an explicit test case that checks for them. It is necessary to
put this test function here because the OMPI_IS* macros are only
defined in this directory.
This commit was SVN r9195.
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.
restoring the PMPI version. A variety of reasons for this:
- mpi.h was blinding using inline in a C header without the configrue mojo
properly set it, as mpi.h doesn't include ompi_config.h. This eventually
would have caused a borked build.
- mpi.h and mpif.h were never updated to not include PMPI_W{tick,time} as
a proper prototype
- The C++ and F90 bindings didn't do the right things when there was no
PMPI version of the C call, but profiling was enabled
- Since we only use gettimeofday, the function call overhead really doesn't
matter
This should probably go to the 1.0 branch
This commit was SVN r8014.
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.
