| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Fix Qt with OpenGL on the Mac.
Add .git .bzr and .hg to the list of default CPack ignore directories.
Bump RC number
Update ChangeLog.manual
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit cherry-picks and squashes the following commits:
4685872 "FortranCInterface: Fix PathScale detection..." (2010-02-16)
b39fe94 "Fix problem with ExternalProject test..." (2010-02-17)
70290e1 "Add support for QtDeclartive module" (2010-02-17)
282ba89 "Clarify CMAKE_MODULE_PATH documentation" (2010-02-18)
4eba05d "Suppress GNU flag -fPIC on Windows" (2010-02-19)
57efb4a "BUG: We shouldn't be setting the HideWindow..." (2010-02-19)
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
The --force-new-ctest-process option does not do anything in the context
where we added it, so we remove the useless change.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CTest 2.6.4 crashes if a dashboard script invokes "message()" after
"ctest_test()" or anything else that creates an inner cmCTest object.
The CMake.Install test drives installation using --build-and-test with
the outer CTest driving CMake tests. We add --force-new-ctest-process
to avoid creation of a cmCTest object inside the outer CTest just in
case it is 2.6.4.
|
| |
| |
| |
| |
| | |
Commit "Add alternate per-vendor compiler id detection" on this branch
was meant for the main development line.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
affect the RC
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Commit f90bdaf3 ("BUG #10209: Fixed FindwxWidget CXX flags parsing
error.", 2010-05-09) was accidentally based on a "nightly start time"
merge branch and then rebased on commit e30279e7 ("KWSys Nightly Date
Stamp", 2010-05-10) by "hg-git". The rebase brought the whole nightly
merge branch along as empty commits, but the committer times were not
updated during the rebase.
The above led to a series of commit objects whose recorded committer
time predates their parent commits. This confuses Git's date-based
revision selection (like --since="$date") which assumes that commit
object times are always newer than their parents.
We resolved the problem by rebasing history since f90bdaf3 onto
e30279e7. This merge commit combines the two versions of history to
allow branches to fast-forward through here from the original history.
The first parent of this commit is the fixed history and the second
parent is the original history. Now date-based revision selection works
correctly because it can walk through the left of this merge.
|
| | | | |
|
| | | | |
|