Commit "Teach CTest.Update tests to strongly check entries" (2010-02-09)
started checking Update.xml entries strongly. This revealed that some
cvs clients report "U CTestConfig.cmake" during update even though the
file did not change and it selects the same revision. As a result the
test fails with
Update.xml has extra unexpected entries:
Updated{CTestConfig.cmake}
We fix the test to tolerate this particular extra entry without failing.
In the CTest module we previously warned if the source directory did not
contain known version control directories. The message was:
"CTest cannot determine repository type. Please set UPDATE_TYPE
to 'cvs' or 'svn'. CTest update will not work."
This was confusing when building sources from a tarball. Furthermore,
we now support many more version control tools. This feature is now
mature enough that the warning causes confusion more than it provides
real help. We simply remove it.
We wrap the git executable in a shell script that touches one source
file after 'git pull'. This makes the file newer than the index even
though it has not actually changed. If CTest does not refresh the index
properly then the test will fail with a bogus modified file.
We use 'git diff-index' to detect local modifications after pull. On
some filesystems the work tree timestamps of a few files may be dated
after the index, making them appear as locally modified. We address the
problem by using 'git update-index --refresh' to refresh the index and
avoid false local modifications.
Previously these tests just checked for matching file names in the
Update.xml files. Now we check the update types (Updated, Modified, or
Conflicting) and reject unexpected extra entries.
Our internal path processing methods assume no trailing slashes, but bzr
adds trailing slashes to updated directories. This can lead to empty
entries in Update.xml files. We address the problem by stripping the
slashes as soon as they are parsed.
The compiler documents symbols _DF_VERSION_ and _VF_VERSION_ but they do
not seem to be available to the preprocessor. Instead we add a vendor
query table entry for Compaq. Running "f90 -what" produces
Compaq Visual Fortran Optimizing Compiler Version ...
This clearly identifies the compiler.
At least one Fortran compiler does not provide a preprocessor symbol to
identify itself. Instead we try running unknown compilers with version
query flags known for each vendor and look for known output. Future
commits will add vendor-specific flags/output table entries.
The PathScale compiler silently accepts unknown options that start in
more than one '-':
$ touch foo.c
$ pathcc -c foo.c --junk
$ echo $?
0
$ pathcc -c foo.c ---junk
$ echo $?
0
$ pathcc -c foo.c -junk
pathcc ERROR parsing -junk: unknown flag
$ echo $?
2
We teach the TryCompile to pass a bogus flag with only one '-' instead
of three '-'s for this compiler.
We disable this test because PathScale Fortran mangles module symbols as
"MYSUB.in.MYMODULE" so we cannot interface with it from C. We already
did this for SunPro and MIPSpro.
PathScale Fortran mangles module symbols as "MYSUB.in.MYMODULE" and also
requires "mymodule_" when the module is imported. We cannot provide the
symbol with ".in." mangling so we should not provide "mymodule_" because
it would duplicate the one in the Fortran-provided object file.
Brad King
David Cole
KWSys Robot
Bill Hoffman
Zach Mullen
James Bigler
Alexander Neundorf
Dave Partyka