2005-10-17 04:21:10 +04:00
|
|
|
# -*- makefile -*-
|
2004-08-05 18:01:45 +04:00
|
|
|
#
|
2005-11-05 22:57:48 +03:00
|
|
|
# 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.
|
2006-02-07 06:32:36 +03:00
|
|
|
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
2004-11-28 23:09:25 +03:00
|
|
|
# University of Stuttgart. All rights reserved.
|
2005-03-24 15:43:37 +03:00
|
|
|
# Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
|
# All rights reserved.
|
2015-06-24 06:59:57 +03:00
|
|
|
# Copyright (c) 2012 Los Alamos National Security, Inc. All rights reserved.
|
configury: new OPAL_SET_LIB_PREFIX/ORTE_SET_LIB_PREFIX macros
These two macros set the prefix for the OPAL and ORTE libraries,
respectively. Specifically, the OPAL library will be named
libPREFIXopen-pal.la and the ORTE library will be named
libPREFIXopen-rte.la.
These macros must be called, even if the prefix argument is empty.
The intent is that Open MPI will call these macros with an empty
prefix, but other projects (such as ORCM) will call these macros with
a non-empty prefix. For example, ORCM libraries can be named
liborcm-open-pal.la and liborcm-open-rte.la.
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running MPI applications under ORTE, if the ORTE and OPAL
libraries between OMPI and ORCM are not identical (which, because they
are released at different times, are likely to be different), we need
to ensure that the OMPI applications link against their ORTE and OPAL
libraries, but the ORCM executables link against their ORTE and OPAL
libraries.
2014-10-22 16:49:58 +04:00
|
|
|
# Copyright (c) 2014 Cisco Systems, Inc. All rights reserved.
|
2004-11-22 04:38:40 +03:00
|
|
|
# $COPYRIGHT$
|
2006-02-07 06:32:36 +03:00
|
|
|
#
|
2004-11-22 04:38:40 +03:00
|
|
|
# Additional copyrights may follow
|
2006-02-07 06:32:36 +03:00
|
|
|
#
|
2004-08-05 18:01:45 +04:00
|
|
|
# $HEADER$
|
|
|
|
|
#
|
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
# This makefile.am does not stand on its own - it is included from opal/Makefile.am
|
2005-10-17 04:21:10 +04:00
|
|
|
|
|
|
|
|
headers += \
|
2006-02-07 06:32:36 +03:00
|
|
|
dss/dss.h \
|
|
|
|
|
dss/dss_types.h \
|
|
|
|
|
dss/dss_internal.h
|
2005-10-17 04:21:10 +04:00
|
|
|
|
configury: new OPAL_SET_LIB_PREFIX/ORTE_SET_LIB_PREFIX macros
These two macros set the prefix for the OPAL and ORTE libraries,
respectively. Specifically, the OPAL library will be named
libPREFIXopen-pal.la and the ORTE library will be named
libPREFIXopen-rte.la.
These macros must be called, even if the prefix argument is empty.
The intent is that Open MPI will call these macros with an empty
prefix, but other projects (such as ORCM) will call these macros with
a non-empty prefix. For example, ORCM libraries can be named
liborcm-open-pal.la and liborcm-open-rte.la.
This scheme is necessary to allow running Open MPI applications under
systems that use their own versions of ORTE and OPAL. For example,
when running MPI applications under ORTE, if the ORTE and OPAL
libraries between OMPI and ORCM are not identical (which, because they
are released at different times, are likely to be different), we need
to ensure that the OMPI applications link against their ORTE and OPAL
libraries, but the ORCM executables link against their ORTE and OPAL
libraries.
2014-10-22 16:49:58 +04:00
|
|
|
lib@OPAL_LIB_PREFIX@open_pal_la_SOURCES += \
|
2006-02-07 06:32:36 +03:00
|
|
|
dss/dss_internal_functions.c \
|
|
|
|
|
dss/dss_compare.c \
|
|
|
|
|
dss/dss_copy.c \
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
dss/dss_dump.c \
|
2006-02-07 06:32:36 +03:00
|
|
|
dss/dss_load_unload.c \
|
|
|
|
|
dss/dss_lookup.c \
|
|
|
|
|
dss/dss_pack.c \
|
|
|
|
|
dss/dss_peek.c \
|
|
|
|
|
dss/dss_print.c \
|
|
|
|
|
dss/dss_register.c \
|
|
|
|
|
dss/dss_unpack.c \
|
|
|
|
|
dss/dss_open_close.c
|