1
1
Commit Graph

8 Commits

Author SHA1 Message Date
Ralph Castain
a8e2d6c3a6 The bulk of the remaining renaming changes, in one final glorious "blob". Thanks to Jeff for some help chasing down a few spots. Per chat with Jeff, we decided to cleanup a few things that were historical in nature:
top_ompi_srcdir  ->  OMPI_TOP_SRCDIR
top_ompi_builddir -> OMPI_TOP_BUILDDIR

We also split the srcdir/builddir flags according to their local tree (e.g., OPAL_TOP_SRCDIR), and tied them all together in configure.ac. Renamed ompi_ignore and ompi_unignore to be opal_<foo> as these are agnostic markers.

Only thing left is ompilibdir being treated similar to what we dif for srcdir/builddir. Coming soon.

This commit was SVN r31678.
2014-05-07 21:48:53 +00:00
Ralph Castain
abb432aef6 The portable_platform file moved to opal at some point, but this .m4 didn't get updated to match.
Thanks to Paul Hargrove for spotting it and providing a patch!

cmr=v1.7.4:reviewer=jsquyres

This commit was SVN r30320.
2014-01-18 03:19:34 +00:00
Brian Barrett
9780043456 re-apply r29608 and fix the broken configure test that broke worse with the
patch.  See ticket #3885, comment 10 for an explination of why calling
_STRINGIFY on something that's not a numerical constant is always a bad idea.

This commit was SVN r29613.

The following SVN revision numbers were found above:
  r29608 --> open-mpi/ompi@b71bd51cdd
2013-11-05 22:41:10 +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
Ralph Castain
13d86e100b Courtesy of Ralph and Jeff:
Continue the reorganization of the configure system. Move files from the main config directory to their appropriate level-specific config directories. Modify the configure system to correctly handle compiler detection, test, and setup so that all things pertaining to opal and orte are done at the lower level, with the ompi configure system only looking at mpi-specific options.

Ensure the wrapper compilers for orte and ompi only get built when appropriate. Add support for c++ to the orte wrapper compilers, both script and non-script versions.

This commit was SVN r22138.
2009-10-24 01:04:35 +00:00
Rainer Keller
1b8d0cf146 - AC_TRY_RUN does not work in case of cross-compilation environments.
Tests based on preprocessor CPP output, won't help either, as they
   don't spit out nice computed numerical values, but rather the
   #define itselve.

This commit was SVN r21364.
2009-06-04 13:00:16 +00:00
Rainer Keller
9ef87898e0 (originally, did not want to do this during business hours, but
well..)
 - As Jeff suggested, for m4 macros, dont use _ OPAL, but
   rather OPAL_ prefix
 - Set the variable before AC_SUBST, so that replacement happens
   in f77 header-file, too.

This commit was SVN r21316.
2009-05-28 20:28:43 +00:00
Rainer Keller
916eb1fb1e - As proposed in RFC and telcon, warn the user about deprecated
functionality (per MPI-2.1). This warning can be toggled using
   --enable-mpi-interface-warning (default OFF), but can be
   selectively turned on passing
       mpicc -DOMPI_WANT_MPI_INTERFACE_WARNING

   Using icc, gcc < 4.5, warnings (such as in mpi2basic_tests) show:
     type_vector.c:83: warning: ‘MPI_Type_hvector’ is deprecated
     (declared at /home/../usr/include/mpi.h:1379)

   Using gcc-4.5 (gcc-svn) these show up as:
     type_vector.c:83: warning: ‘MPI_Type_hvector’ is deprecated
     (declared at /home/../usr/include/mpi.h:1379):
     MPI_Type_hvector is superseded by MPI_Type_create_hvector in MPI-2.0


   Jeff and I propose to turn such warnings on with Open MPI-1.7 by default.


 - Detection of user-level compiler is handled using the preprocessor
   checks of GASnet's other/portable_platform.h (thanks to Paul Hargrove
   and Dan Bonachea) adapted into ompi/include/mpi_portable_platform.h
   (see comments).

   The OMPI-build time detection is output (Familyname and Version)
   with ompi_info.

   This functionality (actually any upcoming __attribute__) are turned
   off, if a different compiler (and version) is being detected.


 - Note, that any warnings regarding (user-compiler!=build-compiler)
   as discussed in the RFC are _not_ included for now.


 - Tested on Linux with --enable-mpi-interface-warning on
   Linux, gcc-4.5 (deprecated w/ specific msg)
   Linux, gcc-4.3 (deprecated w/o specific msg)
   Linux, pathscale 3.1 (deprecated w/o specific msg)
   Linux, icc-11.0 (deprecated w/o specific msg)

   Linux, PGI-8.0.6 accepts __deprecated__ but does not issue a warning,
   further investigation needed...

This commit was SVN r21262.
2009-05-22 04:39:43 +00:00