This is just manually tested for now.  But this is coming along nicely.

This is not completely finished but it does the basic pass through and back.

…ESTAMP()

This includes regexes that exclude known build-related files should not
trigger a rebuild.

For some reason, this was printing different numbers of "'" at the beginning.
Seems I was formating the print -printf argument wrong.

With this, you can now make any change to the source tree and trigger the
build exteranal_func/ directory to get blow away and rebuilt again.

This explains that %T@ gives the seconds since Jan. 1, 1970, 00:00 GMT.

This new function determines if a package needs to be rebuilt at configure
time in one call.

I updated the WrapExteranl package to use this.

I will add autoamted tests as soon as I am sure this is not impractical for
VERA MOOSEExt/MOOSE for which is was designed.

When the build dir does not exist, you can't search it for files.  Also, if
you filter out all of the modified files there is nothing to do.

This is just more of an example of how badly I need an automated test.  Soon
...

…inos into raw_modified_check_3071

Conflicts:
	cmake/tribits/package_arch/TribitsGetMostRecentFileTimestamp.cmake

I changed the filters to filter out all *.cmake files from the binary
directory.  This is needed to filter out the <test-name>.cmake files that are
currently being written and updated every time by the
TRIBITS_ADD_ADVANCED_TEST() script.

When you have git repos in your source tree and you do some git stuff, this
was triggering a rebuild even though no source changed.  This was discovered
as part of the MOOSEExt/MOOSE build (CASL_MOOSE package).

…ternal

I have updated this test to copy TribitsExampleProject to the test dir and to
do several several reconfigure and rebuilds testing out rebuilds with changes
upstream files in source and build dir.

This software is not unit tested right now so that is the only test we have.
However, it is a pretty nice acceptance test and it does not take that much
longer to run.

…Kanban #3071)

Build/Test Cases Summary
Enabled Packages: TriBITS, CASL_MOOSE
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=218,notpassed=0 (40.65 min)
1) SERIAL_RELEASE => passed: passed=136,notpassed=0 (3.01 min)
Other local commits for this build/test group: 849dbd1, 109047b, 35f115a, 278e0c4, 6099eb2, 1f33aa3, b92aff9, 61ea060, 7d72328, 68bca69, 6baa40e, 87081d7, e547baa, 63ecceb, 70a9334, 9016445, 356cc8c

The update was protected in a print if statement.  I need better unit tests
for this part.

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=136,notpassed=0 (0.94 min)
1) SERIAL_RELEASE => passed: passed=136,notpassed=0 (0.87 min)

…PLIBS )

… improvements

Here I did:

* Added detailed doc on the HAVE_XXX_YYY vars for usage as preprocessor macros

* Added "howtos" for adding optional package and TPL dependencies

* Documented the <packageName>_config.h file explicitly

* Other small improvements and edits for typos I saw

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=136,notpassed=0 (0.89 min)
1) SERIAL_RELEASE => passed: passed=136,notpassed=0 (0.86 min)
Other local commits for this build/test group: 1f4c519

Getting ready to add unit testing of SET_TEST_PROPERTIES().

Here I added the wrapper macros TRIBITS_SET_TESTS_PROPERTIES() and
TRIBITS_SET_TEST_PROPERTIES() to wrap SET_TESTS_PROPERTIES() and
SET_PROPERTY(TEST ...), respectively.  These functions are then used to
capture the calls to these functions in unit test mode instead of actually
setting test properties.

I also added the new unit test helper function UNITTEST_HAS_SUBSTR_CONST().

I added a basic unit tests for the default test properties set by
TRIBITS_ADD_TEST() and TRIBITS_ADD_ADVANCED_TEST().  I also added a basic unit
test for the TIMEOUT property.

This is now ready to support the addition of TIMEOUT scaling (PHI Kanban

This was harder than I expected.  In order to allow for fractional scale
factors and not changing eixsting TIMEOUT factors, I had to implement some
pretty specialized code (see TRIBITS_SCALE_TIMEOUT() for details).

See the updated documentation for details.

… Kanban #3423)

My unit tests could not catch this because you don't actually check that the
test is added.

Build/Test Cases Summary
Enabled Packages: TriBITS, VERAIn, VERAIn_CTF, VERAIn_XML
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=332,notpassed=0 (37.95 min)
1) SERIAL_RELEASE => passed: passed=264,notpassed=0 (23.10 min)
Other local commits for this build/test group: 7831ba5, bdf91d8, 5baa998, 6ec6a32

…IMEOUT argument

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=136,notpassed=0 (0.93 min)
1) SERIAL_RELEASE => passed: passed=136,notpassed=0 (0.87 min)
Other local commits for this build/test group: 2d421b1

In some files that haven't been touched in many years, Windows line terminators
(CRLF) were present. This commit replaces those by standard Unix line
terminators (LF) as used by most Unix and Unix-like systems such as GNU/Linux,
and Mac OS X.

See bug #6026.

Darn, I had forgotten to actually scale TIMEOUT for the
TRIBITS_ADD_ADVANCED_TEST().  I added a unit test and added the scaling.

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=136,notpassed=0 (0.90 min)
1) SERIAL_RELEASE => passed: passed=136,notpassed=0 (0.86 min)

Before, all array args got jumbled together and were unreadable.  With this
change, you can read the output very well.

Build/Test Cases Summary
Enabled Packages: TriBITS, Teuchos
0) MPI_DEBUG => passed: passed=249,notpassed=0 (5.23 min)
1) SERIAL_RELEASE => passed: passed=240,notpassed=0 (2.90 min)

This gives TRIBITS_ADD_LIBRARY() a LINKER_LANGUAGE argument just like
TRIBITS_ADD_EXECUTABLE().  Also, a new function Created function
TRIBITS_SET_LINKER_LANGUAGE_FROM_ARG() to eliminate duplication.

For motivation and details, see Trilinos #6179.

…X (Trilinos #6094)

This is needed because some Trilinos packages did not try very hard to pick
good unique library names.  This will be used to provide a debian release of
Trilinos with the lib prefix "trilinos_".  See Trilinos #6094 for more
details.

I have no idea why my merge commit has all these STK conflicts.  There is
something really evil going on here with STK that I don't understand.

Conflicts:
	packages/stk/stk_io/testsForDocumentation
	packages/stk/stk_io/unit_tests
	packages/stk/stk_mesh/testsForDocumentation
	packages/stk/stk_mesh/unit_tests
	packages/stk/stk_topology/tests_for_documentation
	packages/stk/stk_topology/unit_tests
	packages/stk/stk_util/testsForDocumentation
	packages/stk/stk_util/unit_tests

Hum, someone did not run the checkin-test.py script before they pushed this
change.  If they had, it would have stopped their push.

This is currently failing in all Trilinos builds of TriBITS on CDash.

…ilinos #6098)

With this change, Trilinos_version.h will only have a single INSTALL() target
created, no mater how many times that:

  TRIBITS_REPOSITORY_CONFIGURE_VERSION_HEADER_FILE( ${REPOSITORY_NAME} ...)

is called.  This avoids the duplicate install of Trilinos_version.h when
Trilinos has to install it again under the Trilinos/SIERRA/ directory.

A single install of this file is needed to avoid problems with creating a
Debian distribution of Trilinos (see Trilinos #6098) for details.

This was put to help out Tpetra and Muelu set LINKER_LANGAUGE when CUDA is
used but instead it seems to have broken it.  I am going to keep the rest of
the refactor part of the commit:

   "Adding LINKER_LANGUAGE to TRIBITS_ADD_LIBRARY() (Trilinos #6179)"

because it provides a nice debug message.

See Trilinos bug #6179 for more details.

Build/Test Cases Summary
Enabled Packages: TriBITS, Tpetra, MueLu
Disabled Packages: CTrilinos,ForTrilinos,PyTrilinos,Didasko,Mesquite,Phdmesh,Pliris,Claps,Amesos2,Ifpack2,STK,FEApp
0) MPI_DEBUG => passed: passed=210,notpassed=0 (13.60 min)
1) SERIAL_RELEASE => passed: passed=190,notpassed=0 (3.76 min)
2) MPI_DEBUG_ST => passed: passed=213,notpassed=0 (39.07 min)
3) SERIAL_RELEASE_ST => passed: passed=192,notpassed=0 (19.38 min)
Other local commits for this build/test group: d737688, 1b7c65e

…os #6122)

The block of of set() commands that set
${PROJECT_NAME}_GENERATE_EXPORT_FILE_DEPENDENCIES must be before the TriBITS
package dependencies are processed.

This fixes all of the failing TriBITS unit tests that failed after the
previous change.

…TALLATION_PATHS() (#6122)

Now that this macro is only setting install paths, the name should be changed
to make that clear.  See Trilinos #6122 for more details.

…#6122)

I chagned the logic to maintain the old TriBITS defaults but instead let each
TriBITS project decide if to use GNUInstallDirs by default or not.  For this
purpose, I have defined the cache variable ${PROJECT_NAME}_USE_GNUINSTALLDIR
with the default provided by ${PROJECT_NAME}_USE_GNUINSTALLDIR_DEFAULT.  If
not specified, TriBITS will set
${PROJECT_NAME}_USE_GNUINSTALLDIR_DEFAULT=FALSE.  That way, we don't break
backward compatibility for all TriBITS projects but we let each TriBITS
project decide on its own what the default should be and we let the user
override that default.  Who could ask for more than that?

Also, I put in an if staement for The CMake version so GNUInstallDirs will not
be used if the version is too old.

I have updated all documentation, including a warning about using PATH
datatype for relative install paths (watch out).

See Trilinos #6122 for more details.

Conflicts:
	cmake/tribits/package_arch/TribitsGlobalMacros.cmake
	packages/stk/stk_io/testsForDocumentation
	packages/stk/stk_io/unit_tests
	packages/stk/stk_mesh/testsForDocumentation
	packages/stk/stk_mesh/unit_tests
	packages/stk/stk_topology/tests_for_documentation
	packages/stk/stk_topology/unit_tests
	packages/stk/stk_util/testsForDocumentation
	packages/stk/stk_util/unit_tests

Build/Test Cases Summary
Enabled Packages: TriBITS, Teuchos
Disabled Packages: CTrilinos,ForTrilinos,PyTrilinos,Didasko,Mesquite,Phdmesh,Pliris,Claps,Amesos2,Ifpack2,STK,FEApp
0) MPI_DEBUG => passed: passed=246,notpassed=0 (5.05 min)
1) SERIAL_RELEASE => passed: passed=239,notpassed=0 (2.57 min)
2) MPI_DEBUG_ST => passed: passed=249,notpassed=0 (5.23 min)
3) SERIAL_RELEASE_ST => passed: passed=240,notpassed=0 (2.82 min)
Other local commits for this build/test group: 6fcaeb4, d650234, b238360, ef01514, 299e787, 8911ee8

Something messed up is going on with thse packages/stk conflicits?

Conflicts:
	packages/stk/stk_io/unit_tests
	packages/stk/stk_mesh/unit_tests
	packages/stk/stk_util/unit_tests

Conflicts:
	cmake/tribits/doc/build_quick_ref/TribitsBuildQuickRef.pdf
	cmake/tribits/doc/developers_guide/TribitsDevelopersGuide.pdf
	cmake/tribits/package_arch/TribitsGlobalMacros.cmake

…graph

… #6168)

The IMPORTEDLIBS <lib0> <lib1> ... argument currently addes the <lib0> <lib1>
etc. to the package's ${PACAKGE_NAME}_LIBRARIES variable.  This is bad because
this list of libraries was being passed to EXPORT(TARGETS ...) and was causing
a configure-time failure when "IMPORTEDLIBS m" was used (see Trilinos #6068,
comment 37).

Really we should *not* be adding IMPORTEDLIBS to ${PACAKGE_NAME}_LIBRARIES.
They are already being linked into CMake-built libraries that CMake knows
about.  However, it seems that the Trilinos package TriKota is currently
pulling in Dakota-built libraries using IMPORTEDLIBS so I think we may break
the export files if we remove IMPORTEDLIBS from ${PACAKGE_NAME}_LIBRARIES.

The temporary solution I came up with was to filter the set fo libraries in
${PACAKGE_NAME}_LIBRARIES with IF (TARGET <libName>) and only pass those
libraries to EXPORT(TARGETS ...).  That seems to do the trick.  Now we can
pass in "IMPORTEDLIBS m" and "m" will not be passed to EXPORT(TARGETS ...) but
any IMPORTEDLIBS that are actually CMake targets will get passed to
EXPORT(TARGETS ...).  In manually verified this with the Trilinos package
Zoltan.

There is currently no automated testing for any of this export file stuff.
That is a situation that needs to change pretty darn soon.

The new setup of VERA calls the TriBITS directory "TriBITS", not "tribits".
This is not a limitation of the software, just the tests making assumptions.

Build/Test Cases Summary
Enabled Packages: TriBITS, CTeuchos, ForTeuchos, DataTransferKit, MPACT_libs, MPACT_Drivers, Insilico, COBRA_TF, CASL_MOOSE, VRIPSS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=637,notpassed=0 (16.61 min)
1) SERIAL_RELEASE => passed: passed=546,notpassed=0 (1.49 min)
Other local commits for this build/test group: 43abe6b, 5aa669a, 5c4038e, 50aa5fd

This just uses two builds, MPI_DEBUG and SERIAL_RELEASE.  The DEBUG and
RELEASE parts are not very significant but it is important to test with MPI
enabled and disabled.

Some machines might need to set up the locations of the compilers and
therefore might need a machine-specific checkin-test.py wrapper script.

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=135,notpassed=0 (0.57 min)
1) SERIAL_RELEASE => passed: passed=135,notpassed=0 (0.54 min)
Other local commits for this build/test group: 5c2aa1d

This will be linked to from various sources.

This should allow people to get to the version controlled documentation right
from the README.md file rendered on github.

Not sure it makes sense to generate these PDFs for now as part of this script.
Anyway, github will not render PDF documents, only html documents.

…E (Trilinos #6181)

It turns out that EXECUTE_PROCESS() does not allow OUTPUT_FILE and ERROR_FILE
to point to the same files.  On Unix and Linux, stderr overwrites stdout all
together.  On MS Windows, you get an error if both point to the same file.
See some of the later comments in Trilinos bug #6181 that describe the
problem.

The way that I fixed this problem is to actually just always use
OUTPUT_VARIABLE and ERROR_VARIABLE to capture console output into the same
variable and then write the file specified by the OUTPUT_FILE argument
afterward.  This captures both STDOUT and STDERR.  However, it does not
capture them in the correct order.  However, contrary to documentation
provided by CMake, STDOUT and STDERR may not be interleaved correctly,
especially if MPI is used.  In fact, it may not even output in the correct
order in serial if the machine is loaded.  See the test:

    TriBITS_CTestScripts_cmnd_3_args_1_overall_working_directory

for more details.

I also also put in a warning in the documentation for
TRIBITS_ADD_ADVANCED_TEST() about the usage of OUTPUT_FILE and the strange
behavior of STDOUT and STDERR.

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=135,notpassed=0 (0.56 min)
1) SERIAL_RELEASE => passed: passed=135,notpassed=0 (0.53 min)
Other local commits for this build/test group: a6988b3

For some reason if (WIN32 AND NOT CYGWIN) does not work anymore.

Now all TriBITS tests pass on Windows!

Build/Test Cases Summary
Enabled Packages: TriBITS
Enabled all Forward Packages
0) MPI_DEBUG => passed: passed=135,notpassed=0 (0.56 min)
1) SERIAL_RELEASE => passed: passed=135,notpassed=0 (0.53 min)

It is silly to use DocUtils to generate a simple index.thml file.  Also,
DocUtils does not allow you to create multiple <a href="<link1>" PDF</a>, <a
href="<link2>" PDF</a>, etc. in the document.  This is stupid.

Just get rid of the fluff and have a simple index.thml file.

Once I allow TriBITS to be specified as a package as <projectDir>/TriBITS, you
have to make this change for the tests to pass.

…s #6218)

These changes were done in order to support Trilinos or other projects pulling
in TriBITS as a package from the absolute variable ${PROJECT_NAME}_TRIBITS_DIR
variable.

I added a pretty good unit test and updated the documentation.

This is good info to print in the basic configure output.

…s #6218)

Brent noticied this as part of a problem with automated testing but this was
not causing any problems.

…s #6218)

This allows a little easier setup for TriBITS/Trilinos co-development by just
having to set:

   -D<Project>_TRIBITS_DIR:STRING=TriBITS

and not the full path.  Note the warning about forgetting to use 'STRING'
above.

…racking branch

With this commit, I added the name of the origin repo dir name and the origin
repo SHA1 to the commit message summary.  Now this looks like:

    Automatic snapshot commit from TriBITS at c8d7a01

instead of just

    Automatic snapshot commit

I also updated the script to find out the remote tracking branch and dislay
that instead of assuming origin/master.

The earlier commit 6d07ec56bc83c3e1e085ec33cec089bc49595f07 already fixed
relative paths in export files for package export; this commit does the same
for project export files.

See Trilinos bug #6181.

… project's (TriBITS #5)

As explained in the TriBITS Github issue #5, The TriBITS checkin-test.py
configuration was always getting used instead of the proejct's configuration
file.  This was caused by the commit:

  5c2aa1d "Allow for usage of the checkin-test.py script for TriBITS itself."
  Author: Roscoe A. Bartlett <[email protected]>
  Date:   Fri Sep 5 15:58:24 2014 -0400 (4 days ago)

  A       project-checkin-test-config.py

which exposed a latent defect added way back when TriBITS was first split off
from Trilinos. The problem was that the base directory for the found
<projectDir>/project-checkin-test-config.py was append *not* prepended to
sys.path before including the module with:

    __import__(moduleName).configuration

This was very bad becuase the TriBITS base path automatically gets *prepended*
by python into sys.path just by the checkin-test.py script running the
checkin-test.py script.  Therefore, when I added the file:

   TriBITS/project-checkin-test-config.py

which got snapshotted to:

   Trilinos/cmake/tibits/project-checkin-test-config.py

this logic resulted in this file getting selected for the project's
checkin-test.py configuration file, not the project's:

   Trilinos/project-checkin-test-config.py

file.

By picking up the TriBITSProj project's project-checkin-test-config.py file,
it got --enable-packages=TriBITS and also ignore all of the other
Trilinos-specific MPI_DEBUG and SERIAL_RELEASE options.  Very bad.

Also, as part of this commit, I figured out how to set the default for
--src-dir to the same directory where the project's
project-checkin-test-config.py is found.  That means that checkin-test.py will
automatically pick up the projects project-checkin-test-config.py file as long
as the checkin-test.py script is symlinked into the project's base directory
tree, no matter where it get TriBITS from.  This also allows the
checkin-test.py script under the TriBITSProj build to automatically find the
right project directory.

This is really a great commit if you take this all in!

For GitHub: Fixes #5

This accommodates packages with subpackages (e.g, Trilinos::Teuchos).

…in-test.py (Trilinos #6218)

Now that checkin-test.py will correctly pick up --src-dir given the localtion
of the found project-checkin-test-config.py in the base directory, there is no
longer any reason to have a generic checkin-test.sh wrapper.  Therefore, I
have added the defaults --no-rebase --no-append-test-results directly to the
TriBITSProj project's configuration file.

Now you can push to TriBITS by directly calling the checkin-test.py script and
not bother with a wrapper script.  That will work fine as long as the
compilers and MPI are in your default path.

fix relative path in project export files

IMPORTEDLIBS should have never have been added to ${PACKAGE_NAME}_LIBRARIES.
I think I must have added this very early on in pre-TriBITS development before
anyone ever implemented the export files.

When a TriBITS repo's PackagesList.cmake file uses the macro
TRIBITS_REPOSITORY_DEFINE_PACKAGES() and the repo was defined in the
NativeRepositoriesList.cmake file, the configure would fail because of an
error in logic that would not propertly set the REPOSITORY_NAME variable
before reading in the repo's PackagesList.cmake and TPLsList.cmake files.
This logic has now been fixed.

Here I also added an auotmated test for the usage of the
NativeRepositoriesList.cmake file.  I put in a hook to allow this file to be
specified using ${PROJECT_NAME}_NATIVE_REPO_FILE_OVERRRIDE for unit testing
purposes.  This variable is undocumented on purpose.  I don't want users to
know about it or use it.

Really I want NativeRepositoriesList.cmake to go away and for projects to use
ExtraRepositoriesList.cmake but first I need to implement support for
pre-extra repositories.

Really we should also show git repo SHA1 for development versions to be
precise.

Conflicts:
	package_arch/TribitsWriteClientExportFiles.cmake

This reverts commit 4f36e2c.

Explicitly including the subpackages' configurations isn't necessary anymore
since commit 56a93b1 which added inclusion of
*dependent* packages. Since a package always depends on its subpackages, the
functionality remains the same.

With this changes, the download_cmake.py script will now download and install
CMake 2.8.11 by default.

I also updated the 'rc' and 'dev' versions from what was pulled down by
download_cmake.py.

This is needed so that all of the TriBITS Dashboard Driver run builds will
update to CMake 2.8.11 automatically.

With this changes, the download_cmake.py script will now download and install
CMake 2.8.11 by default.

I also updated the 'rc' and 'dev' versions from what was pulled down by
download_cmake.py.

This is needed so that all of the TriBITS Dashboard Driver run builds will
update to CMake 2.8.11 automatically.

This removes the need for our own custom TribitsConfigVersionTemplate.cmake.in.