diff --git a/cmake/tribits/README.DIRECTORY_CONTENTS.rst b/cmake/tribits/README.DIRECTORY_CONTENTS.rst index 8699e9ebd08a..80067d5a83f8 100644 --- a/cmake/tribits/README.DIRECTORY_CONTENTS.rst +++ b/cmake/tribits/README.DIRECTORY_CONTENTS.rst @@ -1,13 +1,13 @@ TriBITS/tribits/ Directory Contents +++++++++++++++++++++++++++++++++++ -This directory contains the implementation for the varous parts of TriBITS +This directory contains the implementation for the various parts of TriBITS that are used by TriBITS projects to implement TriBITS functionality. It also contains basic documentation in the subdirectory doc/ that is very close to the TriBITS implementation. Files and directories from here are what get installed on the system or will be snapshotted into ``/cmake/tribits/``. Each TriBITS Project decides what parts of -TriBITS it wants to install or shapshot using the script +TriBITS it wants to install or snapshot using the script ``tribits/snapshot_tribits.py`` (which takes arguments for what dirs to snapshot). This directory contains no tests at all. All of the tests for TriBITS are in the ``test/`` directory in the parent TriBITS repository. @@ -46,7 +46,7 @@ If you have a better way to manage multiple builds (e.g. Jenkins) then use that instead. **common_tpls/**: TPLs that are very common and are used by several different -TriBITS projects but are not built into the TriBITS system itslef. Having some +TriBITS projects but are not built into the TriBITS system itself. Having some of these common TPLs in a central location enhances uniformity, reuse, and makes it easier to pull TriBITS packages out of a repo and build them independently. diff --git a/cmake/tribits/ci_support/TribitsDependencies.py b/cmake/tribits/ci_support/TribitsDependencies.py index 6e849261237a..4f728fde37bc 100644 --- a/cmake/tribits/ci_support/TribitsDependencies.py +++ b/cmake/tribits/ci_support/TribitsDependencies.py @@ -207,6 +207,7 @@ class TribitsDependencies: def __init__(self): self.__projectName = None + self.__projectBaseDirName = None self.__packagesList = [] self.__packagesNameToID = {} self.__packagesDirToID = {} @@ -220,6 +221,14 @@ def getProjectName(self): return self.__projectName + def setProjectBaseDirName(self, projectBaseDirName): + self.__projectBaseDirName = projectBaseDirName + + + def getProjectBaseDirName(self): + return self.__projectBaseDirName + + def addPackageDependencies(self, packageDeps): packageName = packageDeps.packageName packageDir = packageDeps.packageDir @@ -558,6 +567,8 @@ def createCDashXML(self): xmlText += "\n" + projectBaseDirName = self.getProjectBaseDirName() + numPackages = self.numPackages() for package_i in range(numPackages): @@ -565,10 +576,13 @@ def createCDashXML(self): packageDeps = self.__packagesList[package_i] packageName = packageDeps.packageName + packagePath = packageDeps.packageDir if packageDeps.parentPackage == "": xmlText += (" \n") + + xmlText += (" "+packagePath+"\n") xmlText += \ " \n"+\ @@ -634,7 +648,10 @@ def getProjectDependenciesFromXmlFile(xmlFile): #print("\npackageDepXmlDom =", dir(packageDepXmlDom)) #print("\npackageDepXmlDom.documentElement =", dir(packageDepXmlDom.documentElement)) projectDependencies = TribitsDependencies() - projectDependencies.setProjectName(packageDepXmlDom.documentElement.getAttribute('project')) + projectDependencies.setProjectName( + packageDepXmlDom.documentElement.getAttribute('project')) + projectDependencies.setProjectBaseDirName( + packageDepXmlDom.documentElement.getAttribute('baseDirName')) for ele in packageDepXmlDom.childNodes[0].childNodes: if ele.nodeType == ele.ELEMENT_NODE: packageName = ele.getAttribute('name') diff --git a/cmake/tribits/ci_support/TribitsDumpXmlDependenciesFiles.cmake b/cmake/tribits/ci_support/TribitsDumpXmlDependenciesFiles.cmake index e3fa73f0f608..88a8fe3def90 100644 --- a/cmake/tribits/ci_support/TribitsDumpXmlDependenciesFiles.cmake +++ b/cmake/tribits/ci_support/TribitsDumpXmlDependenciesFiles.cmake @@ -97,8 +97,11 @@ FUNCTION(TRIBITS_DUMP_DEPS_XML_FILE) SET(DEPS_XM) + GET_FILENAME_COMPONENT(PROJECT_BASE_DIR_NAME "${${PROJECT_NAME}_SOURCE_DIR}" NAME) + LIST(APPEND DEPS_XML - "\n") + "\n" + ) SET(PACKAGE_IDX 0) FOREACH(TRIBITS_PACKAGE ${${PROJECT_NAME}_SE_PACKAGES}) diff --git a/cmake/tribits/ci_support/clone_extra_repos.py b/cmake/tribits/ci_support/clone_extra_repos.py index 105dec136706..cbe8f2ce4669 100755 --- a/cmake/tribits/ci_support/clone_extra_repos.py +++ b/cmake/tribits/ci_support/clone_extra_repos.py @@ -73,7 +73,7 @@ /"""+g_extraRerposFileDefault+r""" -(other repo types can be selected usng --extra-repos-type). +(other repo types can be selected using --extra-repos-type). The list of which repos to clone can be "white-list" selected with the option --extra-repos (see options below for details). Extra repos can in addition be @@ -94,7 +94,7 @@ If the git repo server is using gitolite, one can set --gitolite-root= and that will result in git repos being -selected only if the selcted repos are listed in 'ssh info'. +selected only if the selected repos are listed in 'ssh info'. This allows one to automatically exclude repos from being cloned that the user has no permissions to clone. NOTE: See warning about the --gitolite-root option below! @@ -154,7 +154,7 @@ def injectCmndLineOptionsInParser(clp, gitoliteRootDefault=""): "--extra-repos-type", "extraReposType", g_extraReposTypes , g_extraReposTypesDefaulIdx, "Type of extra repositories to select from " \ - ". When --extra-repos is set, then this arugment" \ + ". When --extra-repos is set, then this argument" \ " is ignored.", clp ) @@ -164,7 +164,7 @@ def injectCmndLineOptionsInParser(clp, gitoliteRootDefault=""): " If specified, then any git repos with the listed as their" \ " root will only be selected if they are listed with 'R' permissions returned" \ " from 'ssh info'. WARNING: Make sure that you have your" \ - " gitoliote SSH registred correctly before using this option by typing" \ + " gitoliote SSH registered correctly before using this option by typing" \ " the command 'ssh info' and make sure that it does *not*" " ask for a password! (Default = '"+gitoliteRootDefault+"')" ) diff --git a/cmake/tribits/core/package_arch/TribitsAddAdvancedTest.cmake b/cmake/tribits/core/package_arch/TribitsAddAdvancedTest.cmake index b2111045c536..3eb0946ff727 100644 --- a/cmake/tribits/core/package_arch/TribitsAddAdvancedTest.cmake +++ b/cmake/tribits/core/package_arch/TribitsAddAdvancedTest.cmake @@ -89,6 +89,12 @@ INCLUDE(PrintVar) # than just grepping STDOUT (e.g. by running separate post-processing programs # to examine output files). # +# The test is only added if tests are enabled for the SE package +# (i.e. `${PACKAGE_NAME}_ENABLE_TESTS`_) or the parent package (if this is a +# subpackage) (i.e. ``${PARENT_PACKAGE_NAME}_ENABLE_TESTS``). (NOTE: A more +# efficient way to optionally enable tests is to put them in a ``test/`` +# subdir and then include that subdir with `TRIBITS_ADD_TEST_DIRECTORIES()`_.) +# # Each atomic test case is either a package-built executable or just a basic # command. An atomic test command block ``TEST_`` (i.e. ``TEST_0``, # ``TEST_1``, ..., up to ``TEST_19``) takes the form:: @@ -404,7 +410,7 @@ INCLUDE(PrintVar) # # If specified, the test command will be assumed to pass if it matches the # given regular expression. Otherwise, it is assumed to fail. TIPS: -# Replace ';' with '[;]' or CMake will interpretet this as a array eleemnt +# Replace ';' with '[;]' or CMake will interpret this as an array elemnt # boundary. To match '.', use '[.]'. # # ``PASS_REGULAR_EXPRESSION_ALL "" "" ... ""`` @@ -413,7 +419,7 @@ INCLUDE(PrintVar) # matches all of the provided regular expressions. Note that this is not # a capability of raw ctest and represents an extension provided by # TriBITS. NOTE: It is critical that you replace ';' with '[;]' or CMake -# will interpretet this as a array eleemnt boundary. +# will interpret this as an array elemnt boundary. # # ``STANDARD_PASS_OUTPUT`` # @@ -740,6 +746,12 @@ FUNCTION(TRIBITS_ADD_ADVANCED_TEST TEST_NAME_IN) # B) Add or don't add tests based on a number of criteria # + SET(ADD_THE_TEST FALSE) + TRIBITS_ADD_TEST_PROCESS_ENABLE_TESTS(ADD_THE_TEST) + IF (NOT ADD_THE_TEST) + RETURN() + ENDIF() + SET(ADD_THE_TEST FALSE) TRIBITS_ADD_TEST_PROCESS_CATEGORIES(ADD_THE_TEST) IF (NOT ADD_THE_TEST) diff --git a/cmake/tribits/core/package_arch/TribitsAddExecutable.cmake b/cmake/tribits/core/package_arch/TribitsAddExecutable.cmake index 3f21dfc31d10..b5d7f8f079eb 100644 --- a/cmake/tribits/core/package_arch/TribitsAddExecutable.cmake +++ b/cmake/tribits/core/package_arch/TribitsAddExecutable.cmake @@ -93,7 +93,7 @@ INCLUDE(CMakeParseArguments) # # ```` # -# The root name of the exectuable (and CMake target) (see `Executable and +# The root name of the executable (and CMake target) (see `Executable and # Target Name (TRIBITS_ADD_EXECUTABLE())`_). This must be the first # argument. # @@ -114,7 +114,7 @@ INCLUDE(CMakeParseArguments) # If passed in, the directory path relative to the package's base # directory (with "/" replaced by "_") is added to the executable name # (see `Executable and Target Name (TRIBITS_ADD_EXECUTABLE())`_). This -# provides a simple way to create unique test exectuable names inside of a +# provides a simple way to create unique test executable names inside of a # given TriBITS package. Only test executables in the same directory # would need to have unique ```` passed in. # @@ -253,7 +253,7 @@ INCLUDE(CMakeParseArguments) # set with the name of the executable target passed to # ``ADD_EXECUTABLE( ... )``. Having this name allows the # calling ``CMakeLists.txt`` file access and set additional target -# propeties (see `Additional Executable and Source File Properties +# properties (see `Additional Executable and Source File Properties # (TRIBITS_ADD_EXECUTABLE())`_). # # .. _Executable and Target Name (TRIBITS_ADD_EXECUTABLE()): @@ -278,7 +278,7 @@ INCLUDE(CMakeParseArguments) # added to the actual executable file name if the option ``NOEXESUFFIX`` is # *not* passed in but this suffix is never added to the target name. # (However, note that on Windows platforms, the default ``*.exe`` extension is -# always added because windows will not run an exectuable in many contexts +# always added because windows will not run an executable in many contexts # unless it has the ``*.exe`` extension.) # # The reason that a default prefix is prepended to the executable and target @@ -355,7 +355,7 @@ FUNCTION(TRIBITS_ADD_EXECUTABLE EXE_NAME) SET(${PARSE_ADDED_EXE_TARGET_NAME_OUT} PARENT_SCOPE) ENDIF() # - # B) Exclude building the test executable based on some several criteria + # B) Exclude building the test executable based on some criteria # SET(ADD_THE_TEST FALSE) diff --git a/cmake/tribits/core/package_arch/TribitsAddTest.cmake b/cmake/tribits/core/package_arch/TribitsAddTest.cmake index 860975ae57b7..eef4e3de3317 100644 --- a/cmake/tribits/core/package_arch/TribitsAddTest.cmake +++ b/cmake/tribits/core/package_arch/TribitsAddTest.cmake @@ -75,6 +75,12 @@ INCLUDE(TribitsAddTestHelpers) # [ADDED_TESTS_NAMES_OUT ] # ) # +# The tests are only added if tests are enabled for the SE package +# (i.e. `${PACKAGE_NAME}_ENABLE_TESTS`_) or the parent package (if this is a +# subpackage) (i.e. ``${PARENT_PACKAGE_NAME}_ENABLE_TESTS``). (NOTE: A more +# efficient way to optionally enable tests is to put them in a ``test/`` +# subdir and then include that subdir with `TRIBITS_ADD_TEST_DIRECTORIES()`_.) +# # *Sections:* # # * `Formal Arguments (TRIBITS_ADD_TEST())`_ @@ -167,7 +173,7 @@ INCLUDE(TribitsAddTestHelpers) # ``POSTFIX_AND_ARGS_`` form instead. **WARNING:** Multiple # arguments passed to a single test invocation must be quoted or multiple # tests taking single arguments will be created instead! See `Adding -# Multiple Tests (TRIBITS_ADD_TEST())`_ for more details and exmaples. +# Multiple Tests (TRIBITS_ADD_TEST())`_ for more details and examples. # # ``POSTFIX_AND_ARGS_ ...`` # @@ -187,7 +193,7 @@ INCLUDE(TribitsAddTestHelpers) # that one can give a meaningful name to each test case and one can # specify multiple arguments without having to quote them and one can # allow long argument lists to span multiple lines. See `Adding Multiple -# Tests (TRIBITS_ADD_TEST())`_ for more details and exmaples. +# Tests (TRIBITS_ADD_TEST())`_ for more details and examples. # # ``COMM [serial] [mpi]`` # @@ -272,7 +278,7 @@ INCLUDE(TribitsAddTestHelpers) # the environment``) for which the test is allowed to be added. If # ``HOSTTYPE`` is specified and ``CMAKE_HOST_SYSTEM_NAME`` is not equal to # one of the values of ````, then the test will **not** be -# added. Typical host system type names include ``Linux``, ``Darwain``, +# added. Typical host system type names include ``Linux``, ``Darwin``, # ``Windows``, etc. # # ``XHOSTTYPE ...`` @@ -347,7 +353,7 @@ INCLUDE(TribitsAddTestHelpers) # with the name(S) of the tests passed to ``ADD_TEST()``. If more than # one test is added, then this will be a list of test names. Having this # name allows the calling ``CMakeLists.txt`` file access and set -# additional test propeties (see `Setting additional test properties +# additional test properties (see `Setting additional test properties # (TRIBITS_ADD_TEST())`_). # # In the end, this function just calls the built-in CMake commands @@ -399,7 +405,7 @@ INCLUDE(TribitsAddTestHelpers) # run in this case. # # NOTE: On native Windows platforms, the ``NOEXESUFFIX`` will still allow -# CTest to run exectuables that have the ``*.exe`` suffix. +# CTest to run executables that have the ``*.exe`` suffix. # # Whatever executable path is specified using this logic, if the executable is # not found, then when ``ctest`` goes to run the test, it will mark it as @@ -459,7 +465,7 @@ INCLUDE(TribitsAddTestHelpers) # # may be preferable since it will not add any postfix name to the test. To # add more than one test case using ``ARGS``, one will use more than one -# quoted set of arugments such as with:: +# quoted set of arguments such as with:: # # ARGS " " " " # @@ -477,7 +483,7 @@ INCLUDE(TribitsAddTestHelpers) # the individual tests can be given more understandable names. # # The other advantage of the ``POSTFIX_AND_ARGS_`` form is that the -# arugments ````, ````, ... do not need to be quoted and can +# arguments ````, ````, ... do not need to be quoted and can # therefore be extended over multiple lines like:: # # POSTFIX_AND_ARGS_0 long_args --this-is-the-first-long-arg=very @@ -804,6 +810,12 @@ FUNCTION(TRIBITS_ADD_TEST EXE_NAME) # B) Add or don't add tests based on a number of criteria # + SET(ADD_THE_TEST FALSE) + TRIBITS_ADD_TEST_PROCESS_ENABLE_TESTS(ADD_THE_TEST) + IF (NOT ADD_THE_TEST) + RETURN() + ENDIF() + SET(ADD_THE_TEST FALSE) TRIBITS_ADD_TEST_PROCESS_CATEGORIES(ADD_THE_TEST) IF (NOT ADD_THE_TEST) diff --git a/cmake/tribits/core/package_arch/TribitsAddTestHelpers.cmake b/cmake/tribits/core/package_arch/TribitsAddTestHelpers.cmake index 7a40df49d85a..e6b030e8452c 100644 --- a/cmake/tribits/core/package_arch/TribitsAddTestHelpers.cmake +++ b/cmake/tribits/core/package_arch/TribitsAddTestHelpers.cmake @@ -192,6 +192,31 @@ FUNCTION(TRIBITS_CONVERT_CMND_ARG_STRING_TO_ADD_TEST_ARG_ARRAY CMND_ARG_STRING A ENDFUNCTION() +# +# Determine if to add the test based on if testing is enabled for the current +# package or subpackage. +# + +FUNCTION(TRIBITS_ADD_TEST_PROCESS_ENABLE_TESTS ADD_THE_TEST_OUT) + IF(${PACKAGE_NAME}_ENABLE_TESTS OR ${PARENT_PACKAGE_NAME}_ENABLE_TESTS) + SET(ADD_THE_TEST TRUE) + ELSE() + IF (PARENT_PACKAGE_NAME STREQUAL PACKAGE_NAME) + SET(PARENT_EANBLE_TESTS_DISABLE_MSG) + ELSE() + SET(PARENT_EANBLE_TESTS_DISABLE_MSG + ", ${PARENT_PACKAGE_NAME}_ENABLE_TESTS='${${PARENT_PACKAGE_NAME}_ENABLE_TESTS}'" + ) + ENDIF() + MESSAGE_WRAPPER( + "-- ${TEST_NAME}: NOT added test because ${PACKAGE_NAME}_ENABLE_TESTS='${${PACKAGE_NAME}_ENABLE_TESTS}${PARENT_EANBLE_TESTS_DISABLE_MSG}'." + ) + SET(ADD_THE_TEST FALSE) + ENDIF() + SET(${ADD_THE_TEST_OUT} ${ADD_THE_TEST} PARENT_SCOPE) +ENDFUNCTION() + + # # Determine if to add the test or not based on [X]HOST and [X]HOSTTYPE arguments # diff --git a/cmake/tribits/core/package_arch/TribitsAdjustPackageEnables.cmake b/cmake/tribits/core/package_arch/TribitsAdjustPackageEnables.cmake index 13dbecbb9ecb..9ad43af941b3 100644 --- a/cmake/tribits/core/package_arch/TribitsAdjustPackageEnables.cmake +++ b/cmake/tribits/core/package_arch/TribitsAdjustPackageEnables.cmake @@ -135,6 +135,8 @@ FUNCTION(TRIBITS_ABORT_ON_MISSING_PACKAGE DEP_PKG PACKAGE_NAME DEP_PKG_LIST_ "Error, the package '${DEP_PKG}' is listed as a dependency of the package" " '${PACKAGE_NAME}' is in the list '${DEP_PKG_LIST_NAME}' but the package" " '${DEP_PKG}' is either not defined or is listed later in the package order." + " This may also be an attempt to create a cicular dependency between" + " the packages '${DEP_PKG}' and '${PACKAGE_NAME}' (which is not allowed)." " Check the spelling of '${DEP_PKG}' or see how it is listed in" " ${PROJECT_NAME}_PACKAGES_AND_DIRS_AND_CLASSIFICATIONS in relationship to" " '${PACKAGE_NAME}'.") @@ -460,7 +462,7 @@ ENDMACRO() # directly setting the variables is that an SE package only needs to list # dependencies that exist. Otherwise, the ``Dependencies.cmake`` file will # need to set all of the above local variables, even those that are empty. -# This is a error checking property of the TriBITS system to avoid misspelling +# This is an error checking property of the TriBITS system to avoid misspelling # the names of these variables. # MACRO(TRIBITS_PACKAGE_DEFINE_DEPENDENCIES) diff --git a/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake b/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake index c67f30458d5d..65eed4d2ae3c 100644 --- a/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake +++ b/cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake @@ -779,7 +779,7 @@ MACRO(TRIBITS_SETUP_INSTALLATION_PATHS) ENDIF() # - # C) Set the cache varibles for the install dirs + # C) Set the cache variables for the install dirs # ADVANCED_SET( ${PROJECT_NAME}_INSTALL_INCLUDE_DIR @@ -1965,6 +1965,23 @@ MACRO(TRIBITS_SETUP_ENV) ENDMACRO() +# +# Set mapping of labels to subprojects (i.e. TriBITS packages) for CTest and +# CDash +# + +MACRO(TRIBITS_SET_LABELS_TO_SUBPROJECTS_MAPPING) + IF (${PROJECT_NAME}_CTEST_USE_NEW_AAO_FEATURES) + SET(CTEST_LABELS_FOR_SUBPROJECTS) + FOREACH(TRIBITS_PACKAGE ${${PROJECT_NAME}_PACKAGES}) + TRIBITS_IS_PRIMARY_META_PROJECT_PACKAGE(${TRIBITS_PACKAGE} PACKAGE_IS_PMPP) + IF (PACKAGE_IS_PMPP) + LIST(APPEND CTEST_LABELS_FOR_SUBPROJECTS ${TRIBITS_PACKAGE}) + ENDIF() + ENDFOREACH() + ENDIF() +ENDMACRO() + # # Macro to turn on CTest support @@ -1984,6 +2001,11 @@ MACRO(TRIBITS_INCLUDE_CTEST_SUPPORT) SET(DART_TESTING_TIMEOUT ${DART_TESTING_TIMEOUT} CACHE STRING "" FORCE) ENDIF() + # Set up CTEst/CDash subprojects + TRIBITS_SET_LABELS_TO_SUBPROJECTS_MAPPING() + # NOTE: We do this after all of the packages have been defined but before + # the DartConfiguration.tcl file has been created. + INCLUDE(CTest) # Generates file DartConfiguration.tcl with 'TimeOut' set! IF (DART_TESTING_TIMEOUT_IN) @@ -2145,7 +2167,6 @@ FUNCTION(TRIBITS_REPOSITORY_CONFIGURE_ALL_VERSION_HEADER_FILES) TRIBITS_REPOSITORY_CONFIGURE_VERSION_HEADER_FILE( ${REPO_NAME} ${REPO_DIR} TRUE "${${PROJECT_NAME}_BINARY_DIR}/${REPO_DIR}/${REPO_NAME}_version.h") ENDFOREACH() - ENDFUNCTION() @@ -2297,8 +2318,9 @@ MACRO(TRIBITS_CONFIGURE_ENABLED_PACKAGES) ENDFOREACH() + # - # C part 2) Loop backwards over ETI packages if ETI is enabled + # D) Loop backwards over ETI packages if ETI is enabled # IF (NOT ${PROJECT_NAME}_TRACE_DEPENDENCY_HANDLING_ONLY) @@ -2343,7 +2365,7 @@ MACRO(TRIBITS_CONFIGURE_ENABLED_PACKAGES) ENDIF() # - # D) Check if no packages are enabled and if that is allowed + # E) Check if no packages are enabled and if that is allowed # ADVANCED_SET( ${PROJECT_NAME}_ALLOW_NO_PACKAGES ON @@ -2369,7 +2391,7 @@ MACRO(TRIBITS_CONFIGURE_ENABLED_PACKAGES) ENDIF() # - # E) Process the global variables and other cleanup + # F) Process the global variables and other cleanup # IF (NOT ${PROJECT_NAME}_TRACE_DEPENDENCY_HANDLING_ONLY) @@ -2617,7 +2639,7 @@ ENDMACRO() # CMake/CPack as a regex that is prefixed by the project's and package's # source directory names so as to not exclude files and directories of the # same name and path from other packages. If ```` is an absolute path -# it it not prefixed but is appended to ``CPACK_SOURCE_IGNORE_FILES`` +# it is not prefixed but is appended to ``CPACK_SOURCE_IGNORE_FILES`` # unmodified. # # In general, do **NOT** put in excludes for files and directories that are diff --git a/cmake/tribits/core/package_arch/TribitsLibraryMacros.cmake b/cmake/tribits/core/package_arch/TribitsLibraryMacros.cmake index 49d359cf64af..f07027de73cb 100644 --- a/cmake/tribits/core/package_arch/TribitsLibraryMacros.cmake +++ b/cmake/tribits/core/package_arch/TribitsLibraryMacros.cmake @@ -234,7 +234,7 @@ ENDFUNCTION() # # ```` # -# Required base name of the library. The name of the actual libray name +# Required base name of the library. The name of the actual library name # will be prefixed by ``${${PROJECT_NAME}_LIBRARY_NAME_PREFIX}`` to # produce:: # @@ -355,7 +355,7 @@ ENDFUNCTION() # If specified, then on output the variable ```` will be # set with the name of the library passed to ``ADD_LIBRARY()``. Having # this name allows the calling ``CMakeLists.txt`` file access and set -# additional target propeties (see `Additional Library and Source File +# additional target properties (see `Additional Library and Source File # Properties (TRIBITS_ADD_LIBRARY())`_). # # .. _Include Directories (TRIBITS_ADD_LIBRARY()): diff --git a/cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake b/cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake index 1f6f7aff5bae..0bce0a671388 100644 --- a/cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake +++ b/cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake @@ -49,7 +49,7 @@ INCLUDE(AppendStringVar) # # @FUNCTION: TRIBITS_PROCESS_ENABLED_TPL() # -# Processs an enabled TPL's FindTPL${TPL_NAME}.cmake module. +# Process an enabled TPL's FindTPL${TPL_NAME}.cmake module. # FUNCTION(TRIBITS_PROCESS_ENABLED_TPL TPL_NAME) diff --git a/cmake/tribits/core/package_arch/TribitsProcessExtraRepositoriesList.cmake b/cmake/tribits/core/package_arch/TribitsProcessExtraRepositoriesList.cmake index 14d4c5c53417..10ff67808096 100644 --- a/cmake/tribits/core/package_arch/TribitsProcessExtraRepositoriesList.cmake +++ b/cmake/tribits/core/package_arch/TribitsProcessExtraRepositoriesList.cmake @@ -103,7 +103,7 @@ INCLUDE(TribitsSortListAccordingToMasterList) # in this repo come before the project's native packages. If the keyword # ``POST`` is provided then the packages are listed after the project's # native packages. The default is assumed to be ``POST`` if neither of -# these keywords are provided. The keywords must be separated by a comm +# these keywords are provided. The keywords must be separated by a comma # with no spaces such as with "``PRE,HASPACKAGES``", # "``HASPACKAGES,POST``", "``POST,NOPACKAGES``", etc. If no keywords are # provided, then the empty string "" must be used (which defaults to diff --git a/cmake/tribits/core/package_arch/TribitsProcessPackagesAndDirsLists.cmake b/cmake/tribits/core/package_arch/TribitsProcessPackagesAndDirsLists.cmake index 2aa90c42e9cf..77fb68fef1c3 100644 --- a/cmake/tribits/core/package_arch/TribitsProcessPackagesAndDirsLists.cmake +++ b/cmake/tribits/core/package_arch/TribitsProcessPackagesAndDirsLists.cmake @@ -77,7 +77,7 @@ INCLUDE(TribitsListHelpers) # TriBITS repo that might be combined into a single TriBITS project # meta-build (see `Globally unique TriBITS package names`_). The name # should be a valid identifier (e.g. matches the regex -# ``[a-zA-Z_][a-zA-Z0-9_]*``). The package names tend to used mixed case +# ``[a-zA-Z_][a-zA-Z0-9_]*``). The package names tend to use mixed case # (e.g. ```SomePackge`` not ``SOMEPACKGE``). # # 1. **DIR** (````): The relative directory for the package diff --git a/cmake/tribits/core/package_arch/TribitsTplFindIncludeDirsAndLibraries.cmake b/cmake/tribits/core/package_arch/TribitsTplFindIncludeDirsAndLibraries.cmake index af68f948df8a..a41267c93364 100644 --- a/cmake/tribits/core/package_arch/TribitsTplFindIncludeDirsAndLibraries.cmake +++ b/cmake/tribits/core/package_arch/TribitsTplFindIncludeDirsAndLibraries.cmake @@ -151,7 +151,7 @@ ENDFUNCTION() # # Function that sets up cache variables for users to specify where to find a # `TriBITS TPL`_'s headers and libraries. This function is typically called -# inside of a ``FindTPL.cmake`` moulde file (see +# inside of a ``FindTPL.cmake`` module file (see # `${TPL_NAME}_FINDMOD`_). # # Usage:: @@ -692,7 +692,7 @@ ENDFUNCTION() # TRIBITS_TPL_TENTATIVELY_ENABLE() # # This function can be called from any CMakeLists.txt file to put a TPL in -# tentative enable mode. But typically, it is called from an SE Pakcage's +# tentative enable mode. But typically, it is called from an SE Package's # `/cmake/Dependencies.cmake`_ file (see `How to tentatively # enable a TPL`_). # @@ -704,7 +704,7 @@ ENDFUNCTION() # not already been set, and sets ``TPL_TENTATIVE_ENABLE_=ON`` in the # cache. # -# NOTE: This function will only tentatively enable a TPL it its enable has not +# NOTE: This function will only tentatively enable a TPL if its enable has not # be explicitly set on input, i.e. if ``-D TPL_ENABLE_=""``. If the # TPL has been explicitly enabled (i.e. ``-D TPL_ENABLE_=ON``) or # disabled (i.e. ``-D TPL_ENABLE_=OFF``), then this function has no diff --git a/cmake/tribits/core/package_arch/TribitsWriteClientExportFiles.cmake b/cmake/tribits/core/package_arch/TribitsWriteClientExportFiles.cmake index ba1100a526e9..6179985da650 100644 --- a/cmake/tribits/core/package_arch/TribitsWriteClientExportFiles.cmake +++ b/cmake/tribits/core/package_arch/TribitsWriteClientExportFiles.cmake @@ -124,7 +124,7 @@ ENDFUNCTION() # Usage:: # # TRIBITS_WRITE_FLEXIBLE_PACKAGE_CLIENT_EXPORT_FILES( -# PACKAGE_NAME +# PACKAGE_NAME # [EXPORT_FILE_VAR_PREFIX ] # [WRITE_CMAKE_CONFIG_FILE ] # [WRITE_EXPORT_MAKEFILE ] @@ -134,7 +134,7 @@ ENDFUNCTION() # # The arguments are: # -# ``PACKAGE_NAME `` +# ``PACKAGE_NAME `` # # Gives the name of the TriBITS package for which the export files should # be created. @@ -143,7 +143,7 @@ ENDFUNCTION() # # If specified, then all of the variables in the generated export files # will be prefixed with ``_`` instead of -# ``_``. +# ``_``. # # ``WRITE_CMAKE_CONFIG_FILE `` # diff --git a/cmake/tribits/core/utils/AddSubdirectories.cmake b/cmake/tribits/core/utils/AddSubdirectories.cmake index 4cc90aa406a9..23d2e7ff1910 100644 --- a/cmake/tribits/core/utils/AddSubdirectories.cmake +++ b/cmake/tribits/core/utils/AddSubdirectories.cmake @@ -40,7 +40,7 @@ # # @MACRO: ADD_SUBDIRECTORIES() # -# Macro that adds a list of subdirectories all at once (removes boiler-place +# Macro that adds a list of subdirectories all at once (removes boiler-plate # code). # # Usage:: diff --git a/cmake/tribits/core/utils/MessageWrapper.cmake b/cmake/tribits/core/utils/MessageWrapper.cmake index 9494014a932b..1b48033df13b 100644 --- a/cmake/tribits/core/utils/MessageWrapper.cmake +++ b/cmake/tribits/core/utils/MessageWrapper.cmake @@ -59,7 +59,7 @@ INCLUDE(GlobalSet) # function. However, when the variable ``MESSAGE_WRAPPER_UNIT_TEST_MODE`` is # set to ``TRUE``, then this function will not call ``MESSAGE(...)`` but # instead will prepend set to the global variable ``MESSAGE_WRAPPER_INPUT`` -# the input argument that would have gon to ``MESSAGE()``. To capture just +# the input argument that would have gone to ``MESSAGE()``. To capture just # this call's input, first call:: # # GLOBAL_NULL_SET(MESSAGE_WRAPPER_INPUT) diff --git a/cmake/tribits/core/utils/ParseVariableArguments.cmake b/cmake/tribits/core/utils/ParseVariableArguments.cmake index e115e00acd4d..07bc84f61071 100644 --- a/cmake/tribits/core/utils/ParseVariableArguments.cmake +++ b/cmake/tribits/core/utils/ParseVariableArguments.cmake @@ -249,11 +249,11 @@ ENDMACRO() # NOTE: If the above function turns out to be a performance bottle neck, there # are a few things that could be done to improve performance. One thing you # could do is repalce the O(len(arg_names)) and O(len(option_names)) lookups -# with O(1) lookups by creating CMake varibles of the name +# with O(1) lookups by creating CMake variables of the name # ${OUTER_FUNC_NAME}_arg_ and then just look of that varible exists # or not. That should use a hash function. That might actually slow things # down for short lists however so we would have to measure, measure, -# measure. I we would have to pass in the function/macro name to disabiguate +# measure. I would have to pass in the function/macro name to disabiguate # the varible names. It would really be better if cmake would provide a # sorted list find operation. That would make this much faster for large # numbers of argument and option names. diff --git a/cmake/tribits/core/utils/PrependSet.cmake b/cmake/tribits/core/utils/PrependSet.cmake index 979abe36ef21..ebfe9ecd90ee 100644 --- a/cmake/tribits/core/utils/PrependSet.cmake +++ b/cmake/tribits/core/utils/PrependSet.cmake @@ -40,7 +40,7 @@ # # @MACRO: PREPEND_SET() # -# Utility macro to prepend elements to a varible (reduces boiler-plate code). +# Utility macro to prepend elements to a variable (reduces boiler-plate code). # # Usage:: # diff --git a/cmake/tribits/core/utils/PrintNonemptyVar.cmake b/cmake/tribits/core/utils/PrintNonemptyVar.cmake index 5cc0845144cd..226a4d0dd902 100644 --- a/cmake/tribits/core/utils/PrintNonemptyVar.cmake +++ b/cmake/tribits/core/utils/PrintNonemptyVar.cmake @@ -52,9 +52,9 @@ INCLUDE(PrintVar) # # Calls ``PRINT_VAR()`` if ``${}`` is not empty. # -FUNCTION(PRINT_NONEMPTY_VAR VARIBLE_NAME) - ASSERT_DEFINED(VARIBLE_NAME) - IF (NOT "${${VARIBLE_NAME}}" STREQUAL "") - PRINT_VAR(${VARIBLE_NAME}) +FUNCTION(PRINT_NONEMPTY_VAR VARIABLE_NAME) + ASSERT_DEFINED(VARIABLE_NAME) + IF (NOT "${${VARIABLE_NAME}}" STREQUAL "") + PRINT_VAR(${VARIABLE_NAME}) ENDIF() ENDFUNCTION() diff --git a/cmake/tribits/ctest_driver/TribitsCTestDriverCoreHelpers.cmake b/cmake/tribits/ctest_driver/TribitsCTestDriverCoreHelpers.cmake index bc11f265e065..4231d0c0f4d4 100644 --- a/cmake/tribits/ctest_driver/TribitsCTestDriverCoreHelpers.cmake +++ b/cmake/tribits/ctest_driver/TribitsCTestDriverCoreHelpers.cmake @@ -888,16 +888,6 @@ MACRO(TRIBITS_FIND_LAST_TEST_FAILED_LOG_FILE) ENDMACRO() -# Set mapping of labels to subprojects for CDash -MACRO(TRIBITS_SET_LABELS_TO_SUBPROJECTS_MAPPING) - IF (${PROJECT_NAME}_CTEST_USE_NEW_AAO_FEATURES) - FOREACH(TRIBITS_PACKAGE ${${PROJECT_NAME}_PACKAGES_TO_DIRECTLY_TEST}) - CTEST_ADD_SUBPROJECT(${TRIBITS_PACKAGE} LABELS ${TRIBITS_PACKAGE}) - ENDFOREACH() - ENDIF() -ENDMACRO() - - # Get names of failed packages from failed tests FUNCTION(TRIBITS_GET_FAILED_PACKAGES_FROM_FAILED_TESTS LAST_TESTS_FAILED_FILE FAILED_PACKAGES_OUT @@ -1201,7 +1191,7 @@ MACRO(TRIBITS_CTEST_ALL_AT_ONCE) "\n***") # - # A) Set up mapping of labels to subprojects and gather configure arguments + # A) Define mapping from labels to subprojects and gather configure arguments # TRIBITS_SET_LABELS_TO_SUBPROJECTS_MAPPING() diff --git a/cmake/tribits/doc/build_ref/TribitsBuildReferenceBody.rst b/cmake/tribits/doc/build_ref/TribitsBuildReferenceBody.rst index 962bfa33efed..acfdda574afc 100644 --- a/cmake/tribits/doc/build_ref/TribitsBuildReferenceBody.rst +++ b/cmake/tribits/doc/build_ref/TribitsBuildReferenceBody.rst @@ -1676,7 +1676,7 @@ most projects is 1500 seconds (see the default value set in the CMake cache). This value gets scaled by `_SCALE_TEST_TIMEOUT`_ and then set as the field ``TimeOut`` in the CMake-generated file ``DartConfiguration.tcl``. The value ``TimeOut`` from this file is what is directly read by the ``ctest`` -exectuable. Timeouts for tests are important. For example, when an MPI +executable. Timeouts for tests are important. For example, when an MPI program has a defect, it can easily hang (forever) until it is manually killed. If killed by a timeout, CTest will kill the test process and all of its child processes correctly. @@ -2422,7 +2422,7 @@ absolute paths, use the data type ``PATH`` as shown above. Setting install RPATH --------------------- -Setting RPATH for installed shared libraries and exectuables +Setting RPATH for installed shared libraries and executables (i.e. ``BUILD_SHARED_LIBS=ON``) can be a little tricky. Some discussion of how raw CMake handles RPATH and installations can be found at: @@ -2444,7 +2444,7 @@ same as the raw CMake default behavior): ``CMAKE_INSTALL_RPATH_USE_LINK_PATH`` which is set to ``TRUE`` by default for most TriBITS projects but is empty "" for raw CMake.) -The above default behavior allows the installed exectuables and libraries to +The above default behavior allows the installed executables and libraries to be run without needing to set ``LD_LIBRARY_PATH`` or any other system environment variables. However, this setting does not allow the installed libraries and executables to be easily moved or relocated. There are several @@ -2501,7 +2501,7 @@ These scenarios in detail are: -D_SET_INSTALL_RPATH=TRUE \ -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE \ - As described above, this allows libraries and exectuables to be used right + As described above, this allows libraries and executables to be used right away once installed without needing to set any environment variables. Note that this also allows the installed libraries and executables to be @@ -2560,7 +2560,7 @@ These scenarios in detail are: may help to avoid confusion.) Once the install directories are moved to the final location, the - exectuables can be run without any need to set environment variables. + executables can be run without any need to set environment variables. Note that TriBITS also accepts the directory separator "``:``" for:: diff --git a/cmake/tribits/doc/developers_guide/TribitsDevelopersGuide.rst b/cmake/tribits/doc/developers_guide/TribitsDevelopersGuide.rst index f3dcf07961b6..2ee1ecb2726e 100644 --- a/cmake/tribits/doc/developers_guide/TribitsDevelopersGuide.rst +++ b/cmake/tribits/doc/developers_guide/TribitsDevelopersGuide.rst @@ -43,19 +43,20 @@ modern agile software development best practices. TriBITS is a fairly extensive framework that is built on top of the open-source CMake/CTest/CPack/CDash system (which in itself is a very extensive system of software and tools). The most important thing to remember -is that a software project that use TriBITS are really just a CMake project. +is that a software project that uses TriBITS is really just a CMake project. TriBITS makes no attempt to hide that fact either from the TriBITS project developers or from the users that need to configure and build the software. Therefore, to make effective usage of TriBITS, one must learn the basics of CMake (both as a developer and as a user). In particular, CMake is a -Turning-complete programming language with local and global variables (with -strange scoping rules), macros, functions, targets, commands, and other +Turning-complete programming language with local variables, global variables, macros, functions, targets, commands, and other features. One needs to understand how to define and use variables, macros, and functions in CMake. One needs to know how to debug CMakeLists.txt files and CMake code in general (i.e. using ``MESSAGE()`` print statements). One needs to understand how CMake defines and uses targets for various qualities like libraries, executables, etc. Without this basic understanding of CMake, -one will have trouble resolving problems when they might occur. +one will have trouble resolving problems when they occur. + +.. jfrye: Below paragraph is redundant with table of contents above? The remainder of this documented is structured as follows. First, there is some additional `Background`_ material provided. Then, a detailed @@ -77,14 +78,14 @@ Documentation`_. Finally, several bits of information are provided in the Background ========== -Before diving into the details about TriBITS in the following sections, first -some more background is in order. First, a discussion of `TriBITS Developer -and User Roles`_ is provided to help the reader identify their own role(s) and -to help guide the reader to the appropriate documentation (which may or may -not primarily be in this document). Then, section `CMake Language Overview -and Gotchas`_ tries to orient readers with little to no CMake knowledge or -experience on where to start and provides some warnings about non-obvious -CMake behavior that often trips up new users of TriBITS. +In order to easily find the most appropriate documentation, see the 'TriBITS +Developer and User Roles`_ guide. This guide describes the different roles +that users of TriBITS may play and offers links to relevant sections of the +documentation. Additionally, the reader may wish to review the `CMake Language +Overview and Gotchas`_ section which is meant for users that are new to both +CMake and TriBITS. This section gives a brief overview of getting started with +CMake and provides some warnings about non-obvious CMake behavior that often +trips up new users of TriBITS. TriBITS Developer and User Roles @@ -108,11 +109,8 @@ basics about how to run the ``cmake`` and ``ctest`` executables, how to set CMake cache variables, and the basics of building software by typing ``make`` and running tests with ``ctest``. The proper reference for a TriBITS Project User is the `Project-Specific Build Reference`_. The `TriBITS -Overview`_ document may also be of some help. A TriBITS project user does not -need to know anything about the CMake language itself or any of the TriBITS -macros or functions described in `TriBITS Macros and Functions`_ or really -anything else described in this current document except for `Package -Dependencies and Enable/Disable Logic`_. +Overview`_ document may also be of some help. A TriBITS project user may also +need to consult `Package Dependencies and Enable/Disable Logic`_. .. _TriBITS Project Developer: .. _TriBITS Project Developers: @@ -133,6 +131,8 @@ Guide and Reference document should supply everything such a developer needs to know and more. Only a smaller part of this document needs to be understood and accessed by people assuming this role. +.. jfrye: Add links to parts of document above? + .. _TriBITS Project Architect: .. _TriBITS Project Architects: @@ -175,14 +175,12 @@ author of this document). An explicit goal of this document is to make new `TriBITS Project Architects`_ (i.e. those who would make the decision to adopt TriBITS for their projects), -and new `TriBITS System Developers`_ to help extend and maintain TriBITS. As -TriBITS matures and its requirements further stabilize, the need for a -`TriBITS System Architect`_ will hopefully be diminished. +and new `TriBITS System Developers`_ to help extend and maintain TriBITS. -So depending on the particular role that a reader falls into, this document -may or may not be necessary but instead the `TriBITS Overview`_ or the +Depending on the particular role that a reader falls into, this document +may not be necessary and the `TriBITS Overview`_ or the `BuildReference`_ documents may be more appropriate. Hopefully the -above roles and discussion will help the reader select the right document to +above roles and discussion help the reader select the right document to start with. @@ -193,41 +191,41 @@ TriBITS removes a lot of the boiler plate code needed to write a CMake project. As a result, many people can come into a project that uses TriBITS and quickly start to contribute by adding new source files, adding new libraries, adding new tests, and even adding new TriBITS packages and TPLs; -all without really having learned anything about CMake. One just needs to -copy-and-paste existing example CMake code and files as basically "monkey see, -monkey do". As long as nothing out of the ordinary happens, many people can -get along just fine in this mode for a time. - -However, we have observed that most mistakes that people make when using -TriBITS, and most of the problems they have when using the system, are due to a -basic lack of knowledge of the CMake language. One can find basic tutorials -and references on the CMake language in various locations online for free. +all without really having learned anything about CMake. Often one can use existing +example CMake code as a guide and be successful using basic functionality. As long +as nothing out of the ordinary happens, many people can get along just fine in this +mode for a time. + +However, we have observed that most mistakes and problems that people run into when +using TriBITS are due to lack of basic knowledge of the CMake language. One can find +basic tutorials and references on the CMake language in various locations online for free. One can also purchase the `official CMake reference book`_. Also, documentation for any built-in CMake command is available locally by running:: $ cmake --help-command Because tutorials and detailed documentation for the CMake language already -exists, this document will not even attempt to provide a first reference to -CMake (which is a large topic in itself). However, what we try to provide -below is a short overview of the more quirky or surprising aspects of the -CMake language that a programmer experienced in another language might get -tripped up or surprised by. Some of the more unique features of the language -are described in order to help avoid some of these common mistakes and provide +exists, this document does not attempt to provide a first reference to CMake +(which is a large topic in itself). However, what we try to provide below is +a short overview of the more quirky or surprising aspects of the CMake +language that a programmer experienced in another language might get tripped +up or surprised by. Some of the more unique features of the language are +described in order to help avoid some of these common mistakes and provide greater understanding of how TriBITS works. .. _Official CMake reference book: http://www.cmake.org/cmake/help/book.html -The CMake language that is used to write CMake projects with TriBITS (and that -core TriBITS functionality itself is implemented in, see `TriBITS System -Project Dependencies`_) is a fairly simple programming language with fairly -simple rules (for the most part). However, compared to other programming -languages, there are a few peculiar aspects to the CMake language like strange -variable scoping rules, and how arguments are passed to macros and functions, -that can make working with it difficult if you don't understand these rules. -Also, CMake has some interesting gotchas. In order to effectively use TriBITS -(or just raw CMake) to construct and maintain a project's CMake files, one -must know the basic rules of CMake and be aware of these gotchas. +The CMake language is used to write CMake projects with TriBITS. In fact the +core TriBITS functionality itself is implemented in the CMake language (see +`TriBITS System Project Dependencies`_). CMake is a fairly simple programming +language with relatively simple rules (for the most part). However, compared +to other programming languages, there are a few peculiar aspects to the CMake +language that can make working with it difficult if you don't understand these +rules. For example there are unexpected variable scoping rules and how arguments +are passed to macros and functions can be tricky. Also, CMake has some interesting +gotchas. In order to effectively use TriBITS (or just raw CMake) to construct +and maintain a project's CMake files, one must know the basic rules of CMake +and be aware of these gotchas. The first thing to understand about the CMake language is that nearly every line of CMake code is just a command taking a string (or an array of strings) @@ -265,7 +263,7 @@ string arguments like:: In CMake, the above is identical, in every way, to:: SET(SOME_VARIABLE some_value) - SET("SOME_VARIABLE;"some_value") + SET("SOME_VARIABLE";"some_value") SET("SOME_VARIABLE;some_value") The function ``SET()`` simply interprets the first argument to as the name of @@ -291,11 +289,11 @@ control structures (i.e. see ``cmake --help-command if`` and ``cmake CMake offers a rich assortment of built-in commands for doing all sorts of things. Two of these are the built-in ``MACRO()`` and the ``FUNCTION()`` -commands which allow you to create user-defined macros and functions (which is -what TriBITS is built on). All of these built-in and user-defined macros and -functions work exactly the same way; they take in an array of string -arguments. Some functions take in positional arguments but most actually take -a combination of positional and keyword arguments. +commands which allow you to create user-defined macros and functions. TriBITS +is actually built on CMake functions and macros. All of the built-in and +user-defined macros, and some functions take an array of string arguments. +Some functions take in positional arguments. In fact, most functions take a +combination of positional and keyword arguments. Variable names are translated into their stored values using ``${SOME_VARIABLE}``. The value that is extracted depends on if the variable @@ -468,9 +466,9 @@ listed below: Any of these six OO packaging principles (and other issues) may be considered when deciding how to partition software into different `TriBITS SE Packages`_. -NOTE: This purpose of this TriBITS Developers Guide document is not teach +NOTE: The purpose of this TriBITS Developers Guide document is not teach basic software engineering so these various principles will not be expanded on -further here. However, interested readers are strongly encouraged to read +further. However, interested readers are strongly encouraged to read [`Agile Software Development, 2003`_] as one of the better software engineering books out there (see http://web.ornl.gov/~8vt/readingList.html#Most_Recommended_SE_Books). @@ -478,24 +476,25 @@ http://web.ornl.gov/~8vt/readingList.html#Most_Recommended_SE_Books). TriBITS Project Structure ========================= +.. jfrye: What does the "F" in framework mean? + TriBITS is a Framework, implemented in CMake, to create CMake projects. As a -Framework (with a capital "F"), TriBITS defines the overall structure of a -CMake build system for a project and it processes the various project-, -repository-, and package-specific files in a specified order. Almost all of -this processing takes place in the `TRIBITS_PROJECT()`_ macro (or macros and -functions it calls). The following subsections define the essence of the -TriBITS framework in some detail. Later sections cover specific topics and -the various sections link to each other. Within this section, the subsection -`TriBITS Structural Units`_ defines the basic units `TriBITS Project`_, -`TriBITS Repository`_, `TriBITS Package`_, `TriBITS TPL`_ and other related -structural units. The subsection `Processing of TriBITS Files: Ordering and -Details`_ defines exactly what files TriBITS processes and in what order. It -also shows how to get TriBITS to show exactly what files it is processing to -help in debugging issues. The subsection `Coexisting Projects, Repositories, -and Packages`_ gives some of the rules and constrains for how the different -structure units can co-exist in the same directories. The last two -subsections in this section cover `Standard TriBITS TPLs`_ and `Common TriBITS -TPLs`_. +`Software Framework`_, TriBITS defines the overall structure of a CMake build +system for a project and it processes the various project-, repository-, and +package-specific files in a specified order. Almost all of this processing +takes place in the `TRIBITS_PROJECT()`_ macro (or macros and functions it +calls). The following subsections define the essence of the TriBITS framework +in some detail. Later sections cover specific topics and the various sections +link to each other. Within this section, the subsection `TriBITS Structural +Units`_ defines the basic units `TriBITS Project`_, `TriBITS Repository`_, +`TriBITS Package`_, `TriBITS TPL`_ and other related structural units. The +subsection `Processing of TriBITS Files: Ordering and Details`_ defines +exactly what files TriBITS processes and in what order. It also shows how to +get TriBITS to show exactly what files it is processing to help in debugging +issues. The subsection `Coexisting Projects, Repositories, and Packages`_ +gives some of the rules and constrains for how the different structure units +can co-exist in the same directories. The last two subsections in this +section cover `Standard TriBITS TPLs`_ and `Common TriBITS TPLs`_. TriBITS Structural Units ------------------------ @@ -527,7 +526,7 @@ units are: * `TriBITS Subpackage`_: A part of a parent `TriBITS Package`_ that also typically has source files built into libraries and tests but is documented - and tested along with the other subpackages the parent package. The primary + and tested along with the other subpackages in the parent package. The primary purpose for supporting subpackages is to provide finer-grained control of software dependencies. In `TribitsExampleProject`_, ``WithSubpackages`` is an example of a package with subpackages ``'A'``, ``'B'``, and ``'C'``. The @@ -723,7 +722,7 @@ collection of set statements in this file. **/CMakeLists.txt**: [Required] The top-level CMake project file. This is the first file that the ``cmake`` executable processes that starts everything off and is the base-level scope for local (non-cache) CMake -variables. Due to a few CMake limitations and quarks, a project's top-level +variables. Due to a few CMake limitations and quirks, a project's top-level ``CMakeLists.txt`` file is not quit as clean as one might otherwise hope would be but it is not too bad. A simple, but representative, example is `TribitsExampleProject`_/``CMakeLists.txt``: @@ -731,7 +730,7 @@ be but it is not too bad. A simple, but representative, example is .. include:: ../../examples/TribitsExampleProject/CMakeLists.txt :literal: -A couple of CMake and TriBITS quarks that that above example +A couple of CMake and TriBITS quirks that the above example ``CMakeLists.txt`` addresses are worth some discussion. First, to avoid duplication, the project's ``ProjectName.cmake`` file is read in with an ``INCLUDE()`` that defines the local variable ``PROJECT_NAME``. Right after @@ -1066,7 +1065,7 @@ processed by TriBITS: the built-in ``PROJECT()`` command called in the top-level `/CMakeLists.txt`_ file.. -The following `cache varaibles` are defined for every TriBITS project: +The following `cache variables` are defined for every TriBITS project: .. _${PROJECT_NAME}_TRIBITS_DIR: @@ -1166,7 +1165,7 @@ In short, a TriBITS Repository: respectively) * Defines the base source and binary directories for the Repository ``${REPOSITORY_NAME}_SOURCE_DIR`` and ``${REPOSITORY_NAME}_BINARY_DIR``. -* Defines a common set of initializations and other hooks for a all the +* Defines a common set of initializations and other hooks for all the packages in the repository. * Typically maps to a VC (i.e. git) repository and therefore represents a unit of integration, versioning and reuse. (But core TriBITS has no dependency @@ -1359,7 +1358,7 @@ specific to this TriBITS Repository. This file must define the macro file is processed as the top project-level scope so any local variables set have project-wide effect. This file is processed after the project's `/cmake/CallbackDefineProjectPackaging.cmake`_ file so any project -CPACK varaibles are defined for the repository-level options and commands are +CPACK variables are defined for the repository-level options and commands are created. This file typically just sets extra excludes to remove files from the tarball. The file: @@ -1407,7 +1406,7 @@ are processed: ``${REPOSITORY_NAME}_SOURCE_DIR`` The absolute path to the base of a given TriBITS Repository's source - directory. CMake code, for example in a packages's ``CMakeLists.txt`` + directory. CMake code, for example in a packages' ``CMakeLists.txt`` file, typically refers to this by the raw name like ``RepoX_SOURCE_DIR``. This makes such CMake code independent of where the various TriBITS repos are in relation to each other or the TriBITS Project (but does hard-code @@ -1421,7 +1420,7 @@ are processed: where the various TriBITS repos are in relation to each other or the Project. -The following project-level local varaibles can be defined by the project or +The following project-level local variables can be defined by the project or the user to help define the what packages from the repository ``${REPOSITORY_NAME}`` contribute to the primary meta-project packages (PMPP): @@ -1629,7 +1628,7 @@ The final command in the package's base ``CMakeLists.txt`` file must always be necessary post-processing by TriBITS. It is also possible for the package's top-level ``CMakeLists.txt`` to be the -only ``CMakeLists.txt`` file for a package. Such an example can be see in the +only ``CMakeLists.txt`` file for a package. Such an example can be seen in the example project `TribitsHelloWorld`_ in the ``HelloWorld`` package. When a TriBITS package is broken up into subpackages (see `TriBITS @@ -1659,7 +1658,7 @@ base ``CMakeLists.txt`` file is `TRIBITS_PACKAGE_POSTPROCESS()`_. NOTE: The package's base ``CMakeLists.txt`` file only gets processed if the package is actually enabled (i.e. ``${PROJECT_NAME}_ENABLE_${PACKAGE_NAME}=ON``). This is an important -design feature of TriBITS in that the contents of non-enabled package's can't +design feature of TriBITS in that the contents of non-enabled packages can't damage the configure, build, and test of the enabled packages based on errors in non-enabled packages. This is critical to allow experimental `EX`_ test-group packages and lower-maturity packages to exist in the same source @@ -1685,7 +1684,7 @@ are being processed: ``PACKAGE_NAME`` The name of the current TriBITS SE package. This is set automatically by - TriBITS before the packages's ``CMakeLists.txt`` file is processed. + TriBITS before the packages' ``CMakeLists.txt`` file is processed. **WARNING:** This name must be globally unique across the entire project (see `Globally unique TriBITS package names`_). @@ -1717,7 +1716,7 @@ defined: ``PackageX_SOURCE_DIR``. This makes such CMake code independent of where the package is in relation to other packages. NOTE: This variable is defined for all declared packages that exist, independent of whether they - are enabled or not. This varible is set as soon as it is known if the + are enabled or not. This variable is set as soon as it is known if the given package exists or not. ``${PACKAGE_NAME}_BINARY_DIR`` @@ -1886,10 +1885,9 @@ A TriBITS Subpackage: and/or tests with CMake build targets for building these for which TriBITS exports the list of include directories, libraries, and targets that are created (along with CMake dependencies). -* Is declared in its parent packages's - `/cmake/Dependencies.cmake`_ file in a call to - `TRIBITS_PACKAGE_DEFINE_DEPENDENCIES()`_ using the argument - `SUBPACKAGES_DIRS_CLASSIFICATIONS_OPTREQS`_. +* Is declared in its parent package's `/cmake/Dependencies.cmake`_ + file in a call to `TRIBITS_PACKAGE_DEFINE_DEPENDENCIES()`_ using the + argument `SUBPACKAGES_DIRS_CLASSIFICATIONS_OPTREQS`_. * Defines dependencies on `upstream`_ TPLs and/or other SE packages by just naming the dependencies in the file `//cmake/Dependencies.cmake`_ using the macro @@ -2683,7 +2681,7 @@ Project Core Files`_ and `TriBITS Repository Core Files`_, respectively. Several files from this project are used as examples in the section `TriBITS Project Structure`_. Here, a fuller description is given of this project and -demonstrates some how TriBITS works. From this simple example project, one +a demonstration of how TriBITS works. From this simple example project, one can quickly see how the basic structural elements of a TriBITS project, repository, and package (and subpackage) are pulled together. @@ -3601,7 +3599,7 @@ packages, this can produce a lot of output to stdout. One just needs to understand what TriBITS is printing out and where to look in the output for different information. The examples in the section `Example Enable/Disable Use Cases`_ show what this output looks like for the various enable/disable -scenarios and tries to explains in more detail the reasons for why the given +scenarios and tries to explain in more detail the reasons for why the given behavior is implemented the way that it is. Given this output, the rule definitions given above, and the detailed `Example Enable/Disable Use Cases`_, one should always be able to figure out exactly why the final set of @@ -3635,7 +3633,7 @@ packages in its listed repositories are handled. What these variable do is to allow a large project to turn off the auto-enable of optional SE packages in a given TriBITS repository to provide more detailed control of what gets used from a given TriBITS repository. This, for example, is used in the CASL VERA -project to mange some of its extra repositories and packages to further reduce +project to manage some of its extra repositories and packages to further reduce the number of packages that get auto-enabled. .. ToDo: We should likely change this so that only tests and example don't get @@ -4051,7 +4049,7 @@ TriBITS Automated Testing ========================= Much of the value provided by the TriBITS system is support for testing of -complex complex projects. Many different types of testing are required in a +complex projects. Many different types of testing are required in a complex project and development effort. A large project with lots of repositories and packages provides a number of testing and development challenges but also provides a number of opportunities to do testing in an @@ -4220,7 +4218,7 @@ More detailed descriptions of the test groups are given below. major harm to most developers. Also, code may be marked as ``ST`` if it has required dependencies on ``ST`` TPLs which are either hard to install or may not be available on all platforms where developers do their development and - fro where they push changes to the global repo. In addition, code my be + from where they push changes to the global repo. In addition, code may be marked as ``ST`` if the project is just too big and developers can't be expected to build and test all of this code with every push (so a decision is made to only make some code as ``PT`` so that pushes don't take too @@ -4359,7 +4357,7 @@ The different test test categories are described below in more detail: * Tests marked **HEAVY** are usually reserved for very expensive tests that are too expensive to run nightly. ``HEAVY`` tests require more testing - resources and therefore may only be run on a fully optimzied build and/or + resources and therefore may only be run on a fully optimized build and/or run less frequently. Tests marked as ``HEAVY`` are enabled only for the value of ``${PROJECT_NAME}_TEST_CATEGORIES`` equal to ``HEAVY``. @@ -4522,7 +4520,7 @@ The nightly builds comprise the basic "heart beat" for the project. *Heavy Testing* builds are just an extension to the `Nightly Testing`_ builds that add on more expensive tests marked using the `Test Test Category HEAVY`_. For projects that define heavy tests and heavy builds, individual test cases -may be alloed to take 24 hours or longer to run so they can't even be run +may be allowed to take 24 hours or longer to run so they can't even be run every day in nightly testing. What standard heavy builds have in common is that they tend to select repositories, SE packages and code, and individual tests using the following test-related classifications: @@ -4568,7 +4566,7 @@ Test Test Category ``PERFORMANCE`` (`Test Test Category PERFORMANCE` .. ToDo: I need to set up automated testing for TriBITS to use as the example .. for all of these types of testing. There is no better example that one -.. that actually works. It would also be nice t have a snapshot repo of +.. that actually works. It would also be nice to have a snapshot repo of .. TribitsExampleProject that also had this testing enabled for it but I am .. not sure that really makes sense. @@ -4812,7 +4810,7 @@ developed repository. 2) **REGRESSION_EMAIL_LIST** (defined in `/cmake/Dependencies.cmake`_): Package-specific email address -specified in the packages's ``Dependencies.cmake`` file using +specified in the package's ``Dependencies.cmake`` file using `TRIBITS_PACKAGE_DEFINE_DEPENDENCIES()`_. .. _${REPOSITORY_NAME}_REPOSITORY_EMAIL_URL_ADDRESS_BASE: @@ -5411,7 +5409,7 @@ resulting TriBITS TPL module file ``FindTPL.cmake`` looks like:: With this approach, the ``FindTPL.cmake`` module preserves all of the user behavior described in `Enabling support for an optional Third-Party -Library (TPL)`_ for overriding what TPL componets to look for, where to look +Library (TPL)`_ for overriding what TPL components to look for, where to look and finally to override what is actually used. That is, if the user sets the cache variables ``TPL__INCLUDE_DIRS``, ``TPL__LIBRARIES``, or ``TPL__LIBRARY_DIRS``, then they should be used without question @@ -5442,7 +5440,7 @@ return a list of include directories and libraries. Some, like packages. therefore, in these cases, ``FIND_PACKAGE(Qt4 ...)`` must be called on every configure. In specialized cases such as this, one must write a more specialized ``FindTPL.cmake`` file and can't use the -`TRIBITS_TPL_ALLOW_PRE_FIND_PACKAGE()`_ function like shown shown above. Such +`TRIBITS_TPL_ALLOW_PRE_FIND_PACKAGE()`_ function like shown above. Such find modules cannot completely adhere to the standard behavior described in `Enabling support for an optional Third-Party Library (TPL)`_. @@ -5681,7 +5679,7 @@ be missing. This is demonstrated in `TribitsExampleProject`_ with the package .. include:: ../../examples/TribitsExampleProject/PackagesList.cmake :literal: -In this example, ``InsertedPkg`` has a required dependency on on ``SimpleCxx`` +In this example, ``InsertedPkg`` has a required dependency on ``SimpleCxx`` and the SE package ``WithSubpackagesB`` has an optional dependency on ``InsertedPkg``. Therefore, the inserted package ``InsertedPkg`` has upstream and downstream dependencies on packages in the ``TribitsExampleProject`` repo. @@ -5770,7 +5768,7 @@ following: (either explicitly or through auto enable/disable logic), use:: IF ("${_ENABLE_}" STREQUAL "") - # Variable has not be set to 'ON' or 'OFF' yet + # Variable has not been set to 'ON' or 'OFF' yet ... ENDIF() @@ -6068,7 +6066,7 @@ behavior such as: 3. Some TriBITS projects may require a version of Python more recent than 2.4. In this case, the TriBITS project would set `PythonInterp_FIND_VERSION`_ to - some value higer than ``2.4``. For example, may newer systems have Python + some value higher than ``2.4``. For example, may newer systems have Python 2.6.6 or higher versions installed by default and projects developed on such a system typically requires this version or higher. @@ -6159,7 +6157,7 @@ TriBITS Environment Probing and Setup Part of the TriBITS Framework is to probe the environment, set up the compilers, and get ready to compile code. This was mentioned in `Full Processing of TriBITS Project Files`_. This is executed by the TriBITS macro -``TRIBITS_SETUP_ENV()``. Some of to things this macro does are: +``TRIBITS_SETUP_ENV()``. Some of the things this macro does are: .. _Probe and set up the environment: @@ -6232,7 +6230,7 @@ this allows one to create distributions which only includes subsets of a larger project (even a single package in some cases). Unlike other build systems (like autotools), CMake will put **EVERYTHING** -into the source distribution (e.g. tarball) that it sitting in the source tree +into the source distribution (e.g. tarball) that is sitting in the source tree by default. Therefore, setting up for a source distribution usually means deciding what extra files and directories should be excluded. Beyond the directories for non-enabled packages, further files can be selected to be @@ -6365,7 +6363,7 @@ rebase by default) as shown in the following Trilinos commit:: Define HAVE_TEUCHOSCORE_CXX11 in TeuchosCore_config.h This makes TeuchosCore a good example for how Trilinos (or any TriBITS) - subpackages should put in an optinal dependency on C++11. + subpackages should put in an optional dependency on C++11. Build/Test Cases Summary Enabled Packages: TeuchosCore @@ -6734,7 +6732,7 @@ where, ``SYNC_BASE_DIR=~/sync_base_dir`` for example, which must already be created. Next, one defines a remote to pull changes for the ``ExtraRepo1`` from the -main develoment repo: +main development repo: $ cd $SYNC_BASE_DIR/BaseProj/ExtraRepo1 $ git remote add public url2.gov:/git/ExtraRepo1 @@ -7003,7 +7001,7 @@ After the above cron job starts running (setup described above), the into the underlying ``checkin-test.py`` script. If the emails report an update, configure, build, or test failure, then someone will need to log onto the machine where the ACI sync server is running and investigate what went -wrong, just like they would if the were running the ``checkin-test.py`` script +wrong, just like they would if they were running the ``checkin-test.py`` script for testing locally modified changes before pushing. In the above example, only a single git/TriBITS repo is integrated in this ACI @@ -7033,7 +7031,7 @@ require non-trivial storage and CPU resources (due to the MySQL DB of test results) and requires some amount of extra maintenance. As an intermediate approach, one can consider just using the project's `checkin-test.py`_ script to implement basic post-push CI and/or Nightly testing servers using simple -cron jobs and a some other helper scripts. The ``checkin-test.py`` script +cron jobs and some other helper scripts. The ``checkin-test.py`` script will robustly pull new commits, configure the project, build, run tests, and send out emails with results and pass/fail. A bunch of builds can be run at once using multiple builds specified in the ``--default-builds``, @@ -7067,7 +7065,7 @@ CI and Nightly testing using ``checkin-test.py`` may be quite adequate. In fact, post-push testing processes implemented with ``checkin-test.py`` are much more solid and feature-full than have been employed in many software projects that we have seen over the years that were larger, more public, had -many developers, and and were quite important to many users and development +many developers, and were quite important to many users and development teams. @@ -7312,7 +7310,7 @@ work on all later version GCC and Intel compilers). Hiding deprecated code to certify and facilitate later removal ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -In addition to adding deprecation warnings at preprecessing or compile-time, +In addition to adding deprecation warnings at preprocessing or compile-time, it is also highly desirable to allow the deprecated code to be removed from the build to help certify that client code indeed no longer needs the deprecated code. The following subsections describe how to hide deprecated @@ -7383,7 +7381,7 @@ included in the build and include path and downstream clients can use them. Once these files need to be permanently removed, one just then needs to remove them from the version control repository (i.e. ``git rm ``) -and them remove them from the above ``CMakeLists.txt`` code. +and then remove them from the above ``CMakeLists.txt`` code. Physically removing deprecated code @@ -7595,7 +7593,7 @@ See `snapshot-dir.py --help`_ for more details. Note the guidance on using a different branch for the snapshot sync followed by a merge. This allows for one to maintain local changes to TriBITS and use git to manage the merges. However, this will increase the changes of merge conflicts so one should -consider just directly snapshottting into the master branch to avoid merge +consider just directly snapshotting into the master branch to avoid merge conflicts. @@ -8652,6 +8650,10 @@ Below is a snapshot of the output from ``install_devtools.py --help``. .. _CONFIGURE_FILE(): http://www.cmake.org/cmake/help/v2.8.11/cmake.html#command:configure_file +.. Other references + +.. _Software Framework: https://en.wikipedia.org/wiki/Software_framework + .. LocalWords: TribitsOverview TribitsLifecycleModel Lifecycle CMakeLists .. LocalWords: TriBITS Subpackage subpackage Subpackages subpackages TPL TPLs Kitware .. LocalWords: CMake cmake CTest ctest CDash CPack WithSubpackages WithSubpackagesA diff --git a/cmake/tribits/examples/TribitsExampleMetaProject/ProjectName.cmake b/cmake/tribits/examples/TribitsExampleMetaProject/ProjectName.cmake index 558f3732d501..b36279cf755f 100644 --- a/cmake/tribits/examples/TribitsExampleMetaProject/ProjectName.cmake +++ b/cmake/tribits/examples/TribitsExampleMetaProject/ProjectName.cmake @@ -1,7 +1,7 @@ # Must set the project name at very beginning before including anything else SET(PROJECT_NAME TribitsExMetaProj) -# Turn on export depenency generation for WrapExteranl package +# Turn on export dependency generation for WrapExteranl package SET(${PROJECT_NAME}_GENERATE_EXPORT_FILE_DEPENDENCIES_DEFAULT ON) # Must always have the PRE extra repo TribitsExampleProject/ or can't build diff --git a/cmake/tribits/examples/TribitsExampleProject/ProjectName.cmake b/cmake/tribits/examples/TribitsExampleProject/ProjectName.cmake index 90844f1c1f98..9242e95f70f9 100644 --- a/cmake/tribits/examples/TribitsExampleProject/ProjectName.cmake +++ b/cmake/tribits/examples/TribitsExampleProject/ProjectName.cmake @@ -1,5 +1,5 @@ # Must set the project name at very beginning before including anything else SET(PROJECT_NAME TribitsExProj) -# Turn on export depenency generation for WrapExteranl package +# Turn on export dependency generation for WrapExteranl package SET(${PROJECT_NAME}_GENERATE_EXPORT_FILE_DEPENDENCIES_DEFAULT ON) diff --git a/cmake/tribits/examples/TribitsExampleProject/packages/simple_cxx/CMakeLists.txt b/cmake/tribits/examples/TribitsExampleProject/packages/simple_cxx/CMakeLists.txt index 4d7355a8e418..ab56f71ef592 100644 --- a/cmake/tribits/examples/TribitsExampleProject/packages/simple_cxx/CMakeLists.txt +++ b/cmake/tribits/examples/TribitsExampleProject/packages/simple_cxx/CMakeLists.txt @@ -23,6 +23,6 @@ TRIBITS_ADD_TEST_DIRECTORIES(test) #TRIBITS_ADD_EXAMPLE_DIRECTORIES(example) # -# E) Do standard postprocessing +# E) Do standard post processing # TRIBITS_PACKAGE_POSTPROCESS() diff --git a/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/CMakeLists.txt b/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/CMakeLists.txt index 65979e01c600..7c326f632ba4 100644 --- a/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/CMakeLists.txt +++ b/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/CMakeLists.txt @@ -16,7 +16,7 @@ TRIBITS_ADD_DEBUG_OPTION() TRIBITS_PROCESS_SUBPACKAGES() # -# D) Define the package now and perform standard postprocessing +# D) Define the package now and perform standard post processing # TRIBITS_PACKAGE_DEF() TRIBITS_PACKAGE_POSTPROCESS() diff --git a/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/a/CMakeLists.txt b/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/a/CMakeLists.txt index 7538c5f1c71a..206b1e8510b5 100644 --- a/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/a/CMakeLists.txt +++ b/cmake/tribits/examples/TribitsExampleProject/packages/with_subpackages/a/CMakeLists.txt @@ -23,6 +23,6 @@ TRIBITS_ADD_LIBRARY(pws_a TRIBITS_ADD_TEST_DIRECTORIES(tests) # -# D) Do standard postprocessing +# D) Do standard post processing # TRIBITS_SUBPACKAGE_POSTPROCESS() diff --git a/cmake/tribits/examples/TribitsExampleProjectAddons/ProjectName.cmake b/cmake/tribits/examples/TribitsExampleProjectAddons/ProjectName.cmake index f89c70f77820..0822f2964f49 100644 --- a/cmake/tribits/examples/TribitsExampleProjectAddons/ProjectName.cmake +++ b/cmake/tribits/examples/TribitsExampleProjectAddons/ProjectName.cmake @@ -1,7 +1,7 @@ # Must set the project name at very beginning before including anything else SET(PROJECT_NAME TribitsExProjAddons) -# Turn on export depenency generation for WrapExteranl package +# Turn on export dependency generation for WrapExteranl package SET(${PROJECT_NAME}_GENERATE_EXPORT_FILE_DEPENDENCIES_DEFAULT ON) # Must always have the PRE extra repo TribitsExampleProject/ or can't build diff --git a/cmake/tribits/python_utils/gitdist.py b/cmake/tribits/python_utils/gitdist.py index 760569a668b0..7f652882b186 100755 --- a/cmake/tribits/python_utils/gitdist.py +++ b/cmake/tribits/python_utils/gitdist.py @@ -756,7 +756,7 @@ def getUsageHelpStr(helpTopicArg): def filterWarningsGen(lines): for line in lines: - if not line.startswith(b('warning')) and not line.startswith(b('error')): yield line + if not line.startswith(s('warning')) and not line.startswith(s('error')): yield line # Filter warning and error lines from output @@ -774,8 +774,8 @@ def getCmndOutput(cmnd, rtnCode=False): output = child.stdout.read() child.wait() if rtnCode: - return (output, child.returncode) - return output + return (s(output), child.returncode) + return s(output) # Run a command and syncronize the output @@ -788,7 +788,7 @@ def runCmnd(options, cmnd): child = subprocess.Popen(cmnd, stdout=subprocess.PIPE).stdout output = child.read() sys.stdout.flush() - print(output) + print(s(output)) sys.stdout.flush() @@ -1262,19 +1262,19 @@ def getNumModifiedAndUntracked(options, getCmndOutputFunc): numModified = 0 numUntracked = 0 for line in rawStatusOutput.splitlines(): - if matchFieldOneOrTwo(line.find(b("M"))): + if matchFieldOneOrTwo(line.find(s("M"))): numModified += 1 - elif matchFieldOneOrTwo(line.find(b("A"))): + elif matchFieldOneOrTwo(line.find(s("A"))): numModified += 1 - elif matchFieldOneOrTwo(line.find(b("D"))): + elif matchFieldOneOrTwo(line.find(s("D"))): numModified += 1 - elif matchFieldOneOrTwo(line.find(b("T"))): + elif matchFieldOneOrTwo(line.find(s("T"))): numModified += 1 - elif matchFieldOneOrTwo(line.find(b("U"))): + elif matchFieldOneOrTwo(line.find(s("U"))): numModified += 1 - elif matchFieldOneOrTwo(line.find(b("R"))): + elif matchFieldOneOrTwo(line.find(s("R"))): numModified += 1 - elif line.find(b("??")) == 0: + elif line.find(s("??")) == 0: numUntracked += 1 return (str(numModified), str(numUntracked)) return ("", "")