Merge pull request TriBITSPub#526 from TriBITSPub/63-combined-package…

…-data-structures-init-cleanup

Some initial refactorings and cleanup for combining packages and TPLs (TriBITSPub#63)

test/core/DependencyUnitTests/CMakeLists.txt

@@ -571,12 +571,6 @@ create_dependency_handling_test_case(
   )
 
 
-read_expected_output_file_into_regex_array(
-  "${CMAKE_CURRENT_LIST_DIR}/DepTests_EnableAllPackages_EnableTests_DumpDependencies.txt"
-  EnableAllPackages_EnableTests_DumpDependencies_REGEX_ARRAY
-  )
-#print_var(EnableAllPackages_DumpDependencies_REGEX_ARRAY)
-
 create_dependency_handling_test_case(
   EnableAllPackages_EnableTests_DumpDependencies
   ARGS

test/core/TribitsReadAllProjectDepsFilesCreateDepsGraphHelpers.cmake

@@ -106,7 +106,7 @@ set(${EXTRA_REPO_NAME}_TPLS_FINDMODS_CLASSIFICATIONS)
 
 set(${PROJECT_NAME}_ALL_REPOSITORIES "." "${EXTRA_REPO_NAME}")
 
-set( ${PROJECT_NAME}_ASSERT_MISSING_PACKAGES ON )
+set(${PROJECT_NAME}_ASSERT_MISSING_PACKAGES ON)
 
 
 #####################################################################
@@ -118,7 +118,7 @@ set( ${PROJECT_NAME}_ASSERT_MISSING_PACKAGES ON )
 
 macro(unittest_helper_read_packages_and_dependencies)
 
-  set(${PROJECT_NAME}_ALL_REPOSITORIES)
+  set(${PROJECT_NAME}_ALL_REPOSITORIES "")
   tribits_read_all_project_deps_files_create_deps_graph()
 
 endmacro()

tribits/core/package_arch/TribitsSystemDataStructuresMacrosFunctions.rst

@@ -520,52 +520,5 @@ lists and dependency data-structures described above.
 |             `tribits_append_forward_dep_packages()`_
 |               `tribits_abort_on_missing_package()`_
 
-
-Notes on dependency logic
--------------------------
-
-The logic used to define the intra-package linkage variables is complex due to
-a number of factors:
-
-1) Packages can have libraries or no libraries.  
-
-2) In installation-testing mode, the libraries for a package are read from a
-   file instead of generated in source.
-
-3) A library can be a regular package library, or a test-only library, in
-   which case it will not be listed in ``${PACKAGE_NAME}_LIBRARIES``.  The
-   above description does not even talk about how test-only libraries are
-   handed within the system except to say that they are excluded from the
-   package's exported library dependencies.
-
-The management and usage of the intra-package linkage variables is spread
-across a number of TriBITS ``*.cmake`` files but the primary ones are::
-
-  TribitsPackageMacros.cmake
-  TribitsSubPackageMacros.cmake
-  TribitsLibraryMacros.cmake
-  TribitsAddExecutable.cmake
-
-There are other TriBITS cmake files that also access these variables but these
-are the key files.  The CMake code in these files all work together in
-coordination to set up and use these variables in a way that allows for smooth
-compiling and linking of source code for users of the TriBITS system.
-
-Another file with complex dependency logic related to these variables is::
-
-   TribitsWriteClientExportFiles.cmake
-
-The TriBITS cmake code in this file servers a very similar role for external
-clients and therefore needs to be considered in this setting.
-
-All of these variations and features makes this a bit of a complex system to
-say the least.  Also, currently, there is essentially no unit or regression
-testing in place for the CMake code in these files that manipulate these
-intra-package dependency variables.  Because this logic is tied in with
-actually building and linking code, there has not been a way set up yet to
-allow it to be efficiently tested outside of the actual build.  But there are
-a number of example projects that are part of the automated TriBITS test suite
-that do test much of the logic used in these variables.
-
 ..  LocalWords:  acyclic TriBITS SUBPACKAGES CTEST subpackages buildable TPLs TPLS
 ..  LocalWords:  Subpackage CMake CMakeLists

tribits/core/utils/PrintNonemptyVarWithSpaces.cmake

@@ -43,26 +43,26 @@ include(AppendStringVarWithSep)
 
 # @FUNCTION: print_nonempty_var_with_spaces()
 #
-# Print a defined variable giving its name then value printed with spaces
-# instead of ``';'`` but only if it is not empty.
+# Print a list variable giving its name then value printed with spaces instead
+# of ``';'``, but only if the list is non-empty.
 #
 # Usage::
 #
-#    print_nonempty_var_with_spaces(<varName>  <printedVarInOut>)
+#    print_nonempty_var_with_spaces(<varName>  <printedVarOut>)
 #
 # Prints the variable as::
 #
 #    <varName>: <ele0> <ele1> ...
 #
-# If ``$<printedVarInOut>`` is ``TRUE`` on input, then the variable is not
-# touched. If however, the variable ``$<printedVarInOut>`` is not ``TRUE`` on
-# input, then it is set to ``TRUE`` on output.
+# If ``<printedVarOut>`` is ``TRUE`` on input, then the variable is not
+# touched. If however, the variable ``<printedVarOut>`` is not ``TRUE`` and
+# the list ``<varName>`` in non-empty, then ``<printedVarOut>`` is set to
+# ``TRUE`` on output.
 #
-function(print_nonempty_var_with_spaces  VARIBLE_NAME  PRINTED_VAR_OUT)
-  assert_defined(VARIBLE_NAME)
-  if (NOT "${${VARIBLE_NAME}}" STREQUAL "")
-    string(REPLACE ";" " " OUTSTR "${${VARIBLE_NAME}}")
-    message("-- ${VARIBLE_NAME}: ${OUTSTR}")
-    set(${PRINTED_VAR_OUT} TRUE PARENT_SCOPE)
+function(print_nonempty_var_with_spaces  variableName  printedVarOut)
+  if (NOT "${${variableName}}" STREQUAL "")
+    string(REPLACE  ";"  " "  OUTSTR  "${${variableName}}")
+    message("-- ${variableName}: ${OUTSTR}")
+    set(${printedVarOut}  TRUE  PARENT_SCOPE)
   endif()
 endfunction()

tribits/doc/guides/TribitsGuidesBody.rst

@@ -6668,14 +6668,18 @@ The following steps describe how to submit results to a CDash site using the
 
   * Jenkins jobs can be set up to run them based on various criteria.
 
-  * Travis CI can run them to respond to GitHub pushes.
+  * GitHub Actions can run them to respond to GitHub pushes or to test pull
+    requests.
+
+  * GitLab CI can run them to respond to GitLab pushes or the test merge
+    requests.
 
   * Use the legacy `TriBITS Dashboard Driver`_ system (not recommended).
 
-  The setup of Jenkins, Travis CI and other more sophisticated automated
-  testing systems will not be described here.  What will be briefly outlined
-  below is the setup using cron jobs on a Linux machine.  That is sufficient
-  for most smaller projects and provides tremendous value.
+  The setup of Jenkins, GitHub Actions, GitLab CI and other more sophisticated
+  automated testing systems will not be described here.  What will be briefly
+  outlined below is the setup using cron jobs on a Linux machine.  That is
+  sufficient for most smaller projects and provides tremendous value.
 
   To set up an automated build using a cron job, one will typically create a
   shell driver script that sets the env and then calls the ``ctest -S