The Intel C compiler for Linux does not seem to reject any bad flags or
object files on its link lines. Work around the problem by using a
preprocessor #error directive to ensure that BADFLAG appears in the
build output. This does not really achieve the purpose of the tests but
it allows them to pass.
Double quote executable names that may have spaces in them.
Do not run the new git portions of the test on machines that
have git < version 1.6.5 on them.
The Borland librarian actually creates a BADFLAG.obj when the object is
missing the first time! This causes later tests to not reject it.
Instead use a Borland-specific variation on the flag.
Add archives of these file types and add to the test
cases covered in the ExternalProject test.
Also add an "Example" directory in the Tests/ExternalProject
directory containing the canonical simplest example of
ExternalProject usage.
The LINK_FLAGS property is defined only for targets that really link.
These include executables and shared libraries. For static libraries we
define the STATIC_LIBRARY_FLAGS property. Teach the Xcode generator to
make this distinction.
Add a LinkFlags test series to check that these properties work. Since
no link flag is accepted everywhere we test for presence of flags by
adding a bad flag and looking for the complaint in the test output.
Echo results of calling git status before exiting with
an error. Add one special case so that the test may pass
on the dashmacmini2 continuous dashboard, despite a 'git
status' non-zero return code. More logic like this may
be required. I will re-evaluate based on tomorrow's
nightly dashboard runs.
Additionally, output some more information in both cvs
and git cases. When it is a cvs checkout, echo the contents
of CVS/Root and CVS/Repository to the test output. When it
is a git checkout, echo the output of 'git branch -a'.
This will allow us to see more details about any given CMake
source tree right in the CDash results for this test.
The ENABLE_EXPORTS property exports all symbols from executables on
UNIX-like platforms, typically for use by plugins. Honor this behavior
on Cygwin. See issue #10122.
Improve FILE(DOWNLOAD ...):
- Add percent complete progress output to the FILE DOWNLOAD
command. This progress output is off by default to
preserve existing behavior. To turn it on, pass
SHOW_PROGRESS as an argument.
- Add EXPECTED_MD5 argument. Verify that the downloaded
file has the expected md5 sum after download is complete.
- Add documentation for SHOW_PROGRESS and EXPECTED_MD5.
When the destination file exists already and has the
expected md5 sum, then do not bother re-downloading
the file. ("Short circuit" return.)
Also, add a test that checks for the status output
indicating that the short circuit behavior is actually
occurring. Use a binary file for the test so that the
md5 sum is guaranteed to be the same on all platforms
regardless of "shifting text file line ending" issues.
Improve ExternalProject:
- Add argument URL_MD5.
- Add verify step that compares md5 sum of .tar.gz file
before extracting it.
- Add md5 check to download step, too, to prevent
unnecessary downloads.
- Emit a warning message when a file is not verified.
Indicate that the file may be corrupt or that no
checksum was specified.
Fixes issue http://public.kitware.com/Bug/view.php?id=10258
Also, fix complaint that DOWNLOAD_COMMAND cannot contain arguments
consisting entirely of upper case letters. It validly does when,
for example, you construct a custom cvs command line and the module
name is all upper case, like VTK.
Map to the platform and compiler information for GNU because the
compilers are command-line compatible for common operations. Later we
can add Clang-specific features as necessary. We honor the preferred
capitalization is "Clang", not the common mis-spelling "CLang".
Merge the release branch into master to get its version number, tags,
and ChangeLog. Revert the version on master from 2.9 back to 2.8.
Future releases will be prepared directly in master.
This is the starting point for a branchy workflow based on one described
by the "git help workflows" man page. New development will be done on
local topic branches. Topics will be published by merging them into one
of the integration branches:
maint = Maintenance of previous release
master = Preparation of future release
next = Development of features ("next" to be merged into master)
In order to bootstrap the topic-based workflow from here, all changes in
master since the 2.8 release branch started will either be included in
the next release or reverted and recreated on a topic branch.
Only generate .filters files if they are different than the last time
they were generated. This should prevent the unnecessary reloads
being triggered with Visual Studio 2010 builds.
Brad King
KWSys Robot
David Cole
Bill Hoffman
Yaakov Selkowitz
Clinton Stimpson
Zach Mullen