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

5 Коммитов

Автор SHA1 Сообщение Дата
Ralph Castain
1e2019ce2a Revert "Update to sync with OMPI master and cleanup to build"
This reverts commit cb55c88a8b.
2016-11-22 15:03:20 -08:00
Ralph Castain
cb55c88a8b Update to sync with OMPI master and cleanup to build
Signed-off-by: Ralph Castain <rhc@open-mpi.org>
2016-11-22 14:24:54 -08:00
Ralph Castain
869041f770 Purge whitespace from the repo 2015-06-23 20:59:57 -07:00
Brian Barrett
8231cb62a2 On OpenBSD (and probably others), expr operates on a 32 bit signed integer,
which is the same size as a Fortran or C integer.  This resulted in configure
coming up with Fortran's MAX_INT as -2^31, which obviously isn't a positive
number.  Since we found the MAX_INT using the same broken loop in a couple
places and doing it right is complicated, added a new macro that is much
more careful about sign roll-over.

During the Fortran rework between v1.6 and v1.7, the variable which
indicates whether or not Fortran is being compiled changed, so on platforms
without Fortran compilers, we were trying to determine the max value for
Fortran INTEGERS where we previously didn't.  I believe this is why
bug #3374 appeared as a regression.

Finally, since the OMPI code doesn't cope with OMPI_FORTRAN_HANDLE_MAX
being negative (which was the root cause of the segfault in $3374),
add a check at the end of the OMPI_FORTRAN_GET_HANDLE_MAX macro to
ensure that OMPI_FORTRAN_HANDLE_MAX is always non-negative.

This commit was SVN r27714.
2012-12-22 16:24:36 +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