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.
Alex Neundorf
KWSys Robot
Zach Mullen
Brad King
Ruben Van Boxem
David Cole
Clinton Stimpson
Bill Hoffman
Dave Partyka
Chuck Atkins
Pat Marion
Simon Harvey