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

10 Коммитов

Автор SHA1 Сообщение Дата
Gilles Gouaillardet
661c35ca67 cleanup dead code caused by the removal of the --with-threads configure option 2015-01-16 19:13:59 +09:00
Gilles Gouaillardet
7a55d49ca7 configury: per RFC, remove the --with-threads option 2015-01-16 19:13:59 +09:00
Gilles Gouaillardet
38fdce3aa9 configury: fix a typo in config/opal_config_threads.m4 2014-12-22 18:25:18 +09:00
Ralph Castain
839c0eb55c Per RFC, continue the renaming effort
This commit was SVN r31664.
2014-05-06 21:16:29 +00:00
Brian Barrett
121ca26c59 Per discussion at Develoepr's Meeting, remove Solaris threads support. Solaris
will just fall back to pthreads, which should be no problem.

This commit was SVN r29893.
2013-12-13 20:07:11 +00:00
Brian Barrett
6ef938de3f * Per the Developer's meeting today, restructure the threading in Open MPI a bit
more:
  - Remove OPAL_ENABLE_MULTI_THREADS, since it didn't really do anything
    correctly.  Opal always has threads enabled at this point.
  - Remove OMPI_ENABLE_PROGRESS_THREADS, since this hasn't worked in
    8 years and it has performance issues we'll never be able to
    overcome.  Note that we have plans for re-adding async progress, using
    a hybrid protocol of async and sync sends.
  - OMPI_ENABLE_THREAD_MULTIPLE now determines whether the thread lock
    macros do the check or not.
  - Condition variables are ALWAYS polling right now, which fixes the thread
    live-lock currently found when THREAD_MULTIPLE is turned on.

This commit was SVN r29891.
2013-12-13 19:40:12 +00:00
Ralph Castain
4fdc6f1127 Revise the approach towards the FT options. Include them in a new opal_setup_ft.m4 file. Capture the ft-thread option there as well since it had slipped thru the cracks. Add a detailed comment to configure.ac that describes how to make those options visible, if desired.
This commit was SVN r27969.
2013-01-29 18:30:41 +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
Greg Koenig
e4e064542f This change goes along with r21180 to move files into
the correct names.

This commit was SVN r21181.

The following SVN revision numbers were found above:
  r21180 --> open-mpi/ompi@60485ff95f
2009-05-06 20:15:34 +00:00