ports/openmpi
ports/openmpi
1
1
Форкнуть 0
Код Релизы Активность
581a4b0a4e
openmpi/ompi/tools/ortetools/Makefile.am

56 строки
1.9 KiB
Makefile
Исходник Обычный вид История

Closes ticket #173 : Split name linking up for orte/ompi shared tools. This moves the logic to create the symbolic links for: - mpirun - mpiexec - ompi-ps - ompi-clean and their respective man pages to the ompi level from the orte layer. This is a bit pedantic, but orte shouldn't be doing the work of ompi since that is a bit of an abstraction break. Note: need to autogen.sh to get this. Sorry :( This commit was SVN r10602.
2006-07-01 02:01:56 +04: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.
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
# University of Stuttgart. All rights reserved.
# Copyright (c) 2004-2005 The Regents of the University of California.
# All rights reserved.
# $COPYRIGHT$
#
# Additional copyrights may follow
#
# $HEADER$
#
A few cleanups to the wrapper compiler build system / man pages: - Only install opal{cc,c++} and orte{cc,c++} if configured with --with-devel-headers. Right now, they are always installed, but there are no header files installed for either project, so there's really not much way for a user to actually compile an OPAL / ORTE application. - Drop support for opalCC and orteCC. It's a pain to setup all the symlinks (indeed, they are currently done wrong for opalCC) and there's no history like there is for mpiCC. - Change what is currently opalcc.1 to opal_wrapper.1 and add some macros that get sed'ed so that the man pages appear to be customized for the given command. - Install the wrapper data files even if we compiled with --disable-binaries. This is for the use case of doing multi-lib builds, where one word size will only have the library built, but we need both set of wrapper data files to piece together to activate the multi-lib support in the wrapper compilers. This commit was SVN r12192.
2006-10-19 22:34:17 +04:00
if OMPI_INSTALL_BINARIES
Closes ticket #173 : Split name linking up for orte/ompi shared tools. This moves the logic to create the symbolic links for: - mpirun - mpiexec - ompi-ps - ompi-clean and their respective man pages to the ompi level from the orte layer. This is a bit pedantic, but orte shouldn't be doing the work of ompi since that is a bit of an abstraction break. Note: need to autogen.sh to get this. Sorry :( This commit was SVN r10602.
2006-07-01 02:01:56 +04:00
dist_pkgdata_DATA =
man_MANS = mpirun.1 \
mpiexec.1 \
ompi-ps.1 \
ompi-clean.1
install-exec-hook:
(cd $(DESTDIR)$(bindir); rm -f mpirun$(EXEEXT); $(LN_S) orterun$(EXEEXT) mpirun$(EXEEXT))
(cd $(DESTDIR)$(bindir); rm -f mpiexec$(EXEEXT); $(LN_S) orterun$(EXEEXT) mpiexec$(EXEEXT))
(cd $(DESTDIR)$(bindir); rm -f ompi-ps$(EXEEXT); $(LN_S) orte-ps$(EXEEXT) ompi-ps$(EXEEXT))
(cd $(DESTDIR)$(bindir); rm -f ompi-clean$(EXEEXT); $(LN_S) orte-clean$(EXEEXT) ompi-clean$(EXEEXT))
uninstall-local:
rm -f $(DESTDIR)$(bindir)/mpirun$(EXEEXT) \
$(DESTDIR)$(bindir)/mpiexec$(EXEEXT) \
$(DESTDIR)$(bindir)/ompi-ps$(EXEEXT) \
$(DESTDIR)$(bindir)/ompi-clean$(EXEEXT)
mpirun.1: $(top_srcdir)/orte/tools/orterun/orterun.1
cp -f $(top_srcdir)/orte/tools/orterun/orterun.1 mpirun.1
mpiexec.1: $(top_srcdir)/orte/tools/orterun/orterun.1
cp -f $(top_srcdir)/orte/tools/orterun/orterun.1 mpiexec.1
ompi-ps.1: $(top_srcdir)/orte/tools/orte-ps/orte-ps.1
cp -f $(top_srcdir)/orte/tools/orte-ps/orte-ps.1 ompi-ps.1
ompi-clean.1: $(top_srcdir)/orte/tools/orte-clean/orte-clean.1
cp -f $(top_srcdir)/orte/tools/orte-clean/orte-clean.1 ompi-clean.1
distclean-local:
rm -f mpirun.1 mpiexec.1 ompi-ps.1 ompi-clean.1
A few cleanups to the wrapper compiler build system / man pages: - Only install opal{cc,c++} and orte{cc,c++} if configured with --with-devel-headers. Right now, they are always installed, but there are no header files installed for either project, so there's really not much way for a user to actually compile an OPAL / ORTE application. - Drop support for opalCC and orteCC. It's a pain to setup all the symlinks (indeed, they are currently done wrong for opalCC) and there's no history like there is for mpiCC. - Change what is currently opalcc.1 to opal_wrapper.1 and add some macros that get sed'ed so that the man pages appear to be customized for the given command. - Install the wrapper data files even if we compiled with --disable-binaries. This is for the use case of doing multi-lib builds, where one word size will only have the library built, but we need both set of wrapper data files to piece together to activate the multi-lib support in the wrapper compilers. This commit was SVN r12192.
2006-10-19 22:34:17 +04:00
endif # OMPI_INSTALL_BINARIES
Копировать постоянную ссылку