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.
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.
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.
kFreeBSD and Hurd have the same userland as Linux. This change is
necessary to enable kwsysProcessKill() to kill child processes on
kFreeBSD. The bug was detected by CTestTestTimeout test.
Patch from "Modestas Vainius <modestas@vainius.eu>".
See issue #10432.
This is #10466. It didn't crash for me, but also didn't work.
The issue was that a line ending with something else than a # was considered as the
end of the documentation block. If there was simply the end of the file we didn't
get into the correct branch.
Alex
Add the <Email>...</Email> element in Update.xml for each commit
reported. This field was defined by Dart but never really used.
Distributed version control systems use author name and email
instead of a user id, so now it makes sense to use this field.
The expectation of users of the MSVC60, MSVC70, MSVC71, MSVC80, MSVC90
and the new MSVC10 variables is that at most one of them will be set
for any given build tree. This change enforces that expectation for
build trees using Makefile generators. It also fixes the one mismatch
in that expectation to be found in the Visual Studio generator world:
previously, the VS 7.1 generator would set *both* MSVC70 and MSVC71;
now, it only sets MSVC71.
With these changes, user expectations are now met, and the recently
introduced CheckCompilerRelatedVariables test should pass everywhere.
Since commit "Switch to using libarchive from libtar" (2009-10-30) the
the implementation of "tar xz" has printed all paths from the tarball as
a single line with no separator. This fixes the logic to extract
silently as expected.
Git does not automatically checkout the matching version of a submodule
when it checks out a new version of the parent project in the work tree.
If the submodule reference changed in the parent project then we were
reporting the submodule path as a local modification. Work around the
problem in ctest_update using "git submodule update" after "git pull".
For projects with no submodules this is a no-op. See issue #10662.
Also add a submodule to the test project for CTest.UpdateGIT to test the
work-around.
The PDB file name for VCLinkerTool is specified by the xml attribute
"ProgramDatabaseFile", not "ProgramDataBaseFile" (note the lower-case
character 'b'). VS seems to cope with the incorrect capitalization but
the combination of VS 7.1 and Incredibuild does not. See issue #10614.
Report in <UpdateReturnStatus> when the update command line returns
non-zero. Otherwise the failure may be silently ignored since the error
was previously recorded only in the local log file.
These were implementation details of the unused methods
cmMakefile::RegisterData
cmMakefile::LookupData
We simply remove the methods, members, and class cmData.
For builds from Git repositories, add "-g<commit>" to the end of the
version number. If the source tree is modified, append "-dirty".
For builds from CVS checkouts, add "-cvs-<branch>".
Add the [.tweak] version component throughout the policy implementation.
Document all components for the cmake_policy(VERSION) command. Record
the tweak level in which each policy was introduced (0 for all current
policies). In generated documentation we report the tweak level only if
it is not zero. This preserves existing documentation.
The command now accepts four version components in the format
major[.minor[.patch[.tweak]]]
This corresponds to the new versioning scheme introduced recently.
Prepare to switch to the workflow described by "git help workflows". In
this workflow, the "master" branch is always used to integrate topics
ready for release. Brand new work merges into a "next" branch instead.
We need a new versioning scheme to work this way because the version on
"master" must always increase.
We no longer use an even/odd minor number to distinguish releases from
development versions. Since we still support cvs checkout of our source
tree we cannot depend on "git describe" to compute a version number
based on the history graph. We can use the CCYYMMDD nightly date stamp
to get a monotonically increasing version component.
The new version format is "major.minor.patch.(tweak|date)". Releases
use a tweak level in the half-open range [0,20000000), which is smaller
than any current or future date. For tweak=0 we do not show the tweak
component, leaving the format "major.minor.patch" for most releases.
Development versions use date=CCYYMMDD for the tweak level. The
major.minor.patch part of development versions on "master" always
matches the most recent release.
For example, a first-parent traversal of "master" might see
v2.8.1 2.8.1.20100422 v2.8.2
| | |
----o----o----o----o----o----o----o----o----
Since the date appears in the tweak component, the next release can
increment the patch level (or any more significant component) to be
greater than any version leading to it. Topic branches not ready for
release are published only on "next" so we know that all versions on
master lead between two releases.
Commit "Support more special characters in file(STRINGS)" (2009-10-06)
attempted to support parsing strings from binaries produced by the
Portland Group Fortran compiler. The compiler seems to put an extra
byte just at the end of its string literals. Previously we dealt with
this by explicitly enumerating bytes known to occur, but it seems that
many such possibilities exist. Now we support extraction of strings
that end in any non-ASCII character.
The SaveRestoreEnvironment helper object makes sure that the
original environment is restored immediately after the
StartProcess call returns rather than waiting for the end
of the test. When tests are executed in parallel, there is
no guarantee about the ordering of EndTest calls relative
to StartTest calls. In fact, it would be odd for them to
be nested nicely. Therefore, to avoid the corruption of
the calling ctest's environment, the original environment
must be restored before ForkProcess returns.
Detect the runtime linker's search path and add to the compile time
linker's search path. This is needed because OpenBSD's static linker
does not search for shared library dependencies in the same places as
the runtime linker.
Teach kwsysProcessKill to identify processes on this platform using the "ps"
command just as on Linux. Patch from Modestas Vainius <modax@debian.org>.
See issue #10432.
The compiler id is checked for C++ and C, if there is not one
of those available, then just default to gcc. This makes it
work with Fortran, or None projects.
This makes the behavior of the build with the Visual Studio generators
equivalent to the behavior of makefile based builds. After an error
in a custom command sequence, the build stops and reports an error
rather than executing the remaining commands in the sequence.
Create platform variable "CMAKE_<LANG>_RESPONSE_FILE_LINK_FLAG" to
specify an alternative to "@" for referencing response files. It
applies specifically to response files with linker options.
See issue #10401.
Response files are parsed by tools, not by shells. We teach
cmLocalGenerator::Convert() a new "RESPONSE" output format and use it
for objects listed in response files. It does not do special slash or
MSYS root translation like the "SHELL" format does. This is necessary
for GNU tools on Windows to understand response file content.
See issue #10401.
Allow the user to set the CMake variable CTEST_COST_DATA_FILE, which will be used to store the cost data from test runs. If not set, defaults to the original location in the build tree Testing/Temporary dir.
Ensure that the HTML documentation generated by CMake complies with
"XHTML 1.0 Strict":
- All tags are properly closed and DOCTYPE is specified
- Useful for downstream XML-processors (e.g. for extracting section
titles)
See issue #10338.
Signed-off-by: Simon Harvey <simon.harvey@cambridgeflowsolutions.com>
http://public.kitware.com/Bug/view.php?id=9978
Now instead of one linked resource for each project() just one linked
resource to the top level source directory is created.
This should really avoid this type of name clashes. And to me it looks also
much less confusing.
Hopefully the name "[Source directory]" containing a space and square
brackets doesn't lead to problems somewhere. Here it works.
Alex
In commit 'Create KWSYS_PLATFORM_INFO_TEST macro' (2009-11-20) we
implemented the macro to use a cache entry to avoid re-running the
try_compile(). However, the output copied from the try_compile is
needed on every configure. If the user wipes out the build tree but not
the cache file then the try_compile() will not re-run to recreate the
needed file. We address the problem by teaching the macro to run the
try_compile() whenever its output file does not exist.
We store custom command rule hashes in CMakeFiles/CMakeRuleHashes.txt
persistently across CMake runs. When the rule hash changes we delete
the custom command output file and write a new hash into the persistence
file.
This functionality was first added by the commit 'Introduce "rule
hashes" to help rebuild files when rules change.' (2008-06-02).
However, the implementation in cmGlobalGenerator::CheckRuleHashes kept
the file open for read when attempting to rewrite a new file. On
Windows filesystems this prevented the new version of the file from
being written! This caused the first set of rule hashes to be used
forever within a build tree, meaning that all custom commands whose
rules changed would be rebuilt every time CMake regenerated the build
tree.
In this commit we address the problem by splitting the read and write
operations into separate methods. This ensures that the input stream is
closed before the output stream opens the 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.
KWSys Robot
Brad King
David Cole
Bill Hoffman
Clinton Stimpson
Zach Mullen
Alex Neundorf
Ruben Van Boxem
Dave Partyka
Chuck Atkins
Pat Marion
Simon Harvey