ports/openmpi
ports/openmpi
1
1
Форкнуть 0
Код Релизы Активность
openmpi/orte/mca/ras/loadleveler/configure.m4

41 строка
1.5 KiB
Plaintext
Исходник Обычный вид История

Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
# -*- shell-script -*-
#
# Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
# University Research and Technology
# Corporation. All rights reserved.
# Copyright (c) 2004-2005 The University of Tennessee and The University
# of Tennessee Research Foundation. All rights
# reserved.
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
# University of Stuttgart. All rights reserved.
# Copyright (c) 2004-2005 The Regents of the University of California.
# All rights reserved.
WARNING: Work on the temp branch being merged here encountered problems with bugs in subversion. Considerable effort has gone into validating the branch. However, not all conditions can be checked, so users are cautioned that it may be advisable to not update from the trunk for a few days to allow MTT to identify platform-specific issues. 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.
2010-09-17 23:04:06 +00:00
# Copyright (c) 2009-2010 Cisco Systems, Inc. All rights reserved.
Remove the old configure option for disabling full rte support - we now use the OMPI rte framework for such purposes This commit was SVN r28134.
2013-02-28 01:35:55 +00:00
# Copyright (c) 2011-2013 Los Alamos National Security, LLC.
This is actually a much smaller commit than it appears at first glance - it just touches a lot of files. The --without-rte-support configuration option has never really been implemented completely. The option caused various objects not to be defined and conditionally compiled some base functions, but did nothing to prevent build of the component libraries. Unfortunately, since many of those components use objects covered by the option, it caused builds to break if those components were allowed to build. Brian dealt with this in the past by creating platform files and using "no-build" to block the components. This was clunky, but acceptable when only one organization was using that option. However, that number has now expanded to at least two more locations. Accordingly, make --without-rte-support actually work by adding appropriate configury to prevent components from building when they shouldn't. While doing so, remove two frameworks (db and rmcast) that are no longer used as ORCM comes to a close (besides, they belonged in ORCM now anyway). Do some minor cleanups along the way. This commit was SVN r25497.
2011-11-22 21:24:35 +00:00
# All rights reserved.
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
# $COPYRIGHT$
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
#
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
# Additional copyrights may follow
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
#
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
# $HEADER$
#
# MCA_ras_loadleveler_CONFIG([action-if-found], [action-if-not-found])
# -----------------------------------------------------------
WARNING: Work on the temp branch being merged here encountered problems with bugs in subversion. Considerable effort has gone into validating the branch. However, not all conditions can be checked, so users are cautioned that it may be advisable to not update from the trunk for a few days to allow MTT to identify platform-specific issues. 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.
2010-09-17 23:04:06 +00:00
AC_DEFUN([MCA_orte_ras_loadleveler_CONFIG],[
AC_CONFIG_FILES([orte/mca/ras/loadleveler/Makefile])
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
ORTE_CHECK_LOADLEVELER([ras_loadleveler], [ras_loadleveler_good=1], [ras_loadleveler_good=0])
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
Purge whitespace from the repo
2015-06-23 20:59:57 -07:00
# if check worked, set wrapper flags if so.
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
# Evaluate succeed / fail
Remove the old configure option for disabling full rte support - we now use the OMPI rte framework for such purposes This commit was SVN r28134.
2013-02-28 01:35:55 +00:00
AS_IF([test "$ras_loadleveler_good" = "1"],
Revamp the handling of wrapper compiler flags. The user flags, main configure flags, and mca flags are kept seperate until the very end. The main configure wrapper flags should now be modified by using the OPAL_WRAPPER_FLAGS_ADD macro. MCA components should either let <framework>_<component>_{LIBS,LDFLAGS} be copied over OR set <framework>_<component>_WRAPPER_EXTRA_{LIBS,LDFLAGS}. The situations in which WRAPPER CPPFLAGS can be set by MCA components was made very small to match the one use case where it makes sense. This commit was SVN r27950.
2013-01-29 00:00:43 +00:00
[$1],
Fix for bug #369. LoadLeveler only sets LOADL_PROCESSOR_LIST when there are 128 or less tasks allocated to a job. The POE RAS relied on this variable so I created a new RAS which uses the LoadLeveler API instead of relying on the environment variable. This still needs some testing, so for now we use the POE RAS whenever LOADL_PROCESSOR_LIST, otherwise we fall back on this component. Unfortunately, this will require an autogen... This commit was SVN r11732.
2006-09-21 00:08:49 +00:00
[$2])
# set build flags to use in makefile
AC_SUBST([ras_loadleveler_CPPFLAGS])
AC_SUBST([ras_loadleveler_LDFLAGS])
AC_SUBST([ras_loadleveler_LIBS])
])dnl
Копировать постоянную ссылку