summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Borland-specific bad flag for LinkFlags testsBrad King2010-06-021-6/+9
| | | | | | 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.
* Better "bad" flag in LinkFlags testBrad King2010-06-011-6/+7
| | | | | The Intel C Compiler for Linux ignores _BADFLAG_ when linking! Use a flag that looks like a missing object file to ensure its rejection.
* Watcom: Use LINK_FLAGS and STATIC_LIBRARY_FLAGSBrad King2010-06-011-3/+3
| | | | Add the <LINK_FLAGS> rule variable in Watcom command lines.
* Xcode: Archives use STATIC_LIBRARY_FLAGS, not LINK_FLAGSBrad King2010-05-281-3/+9
| | | | | | | 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 STATIC_LIBRARY_FLAGS_<CONFIG> property (#10768)Brad King2010-05-287-13/+77
| | | | This is a per-configuration version of STATIC_LIBRARY_FLAGS.
* Test LINK_FLAGS and STATIC_LIBRARY_FLAGS (#10768)Brad King2010-05-284-0/+57
| | | | | | 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.
* Implement LINK_FLAGS_<CONFIG> in VS 10 generatorBrad King2010-05-281-0/+14
| | | | | Add support for the per-config LINK_FLAGS property in VS 10. This was simply missing.
* Fix LINK_FLAGS_<CONFIG> in VS 6 generatorBrad King2010-05-281-29/+45
| | | | Add the flags to the link step, not the compile step!
* KWSys Nightly Date StampKWSys Robot2010-05-271-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-261-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-251-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-241-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-231-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-221-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-211-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-201-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-191-1/+1
|
* KWSys Nightly Date StampKWSys Robot2010-05-181-1/+1
|
* ChangeLog: Changes since CMake 2.8.1Brad King2010-05-171-0/+63
|
* Merge CMake 2.8.1 to start branchy workflowBrad King2010-05-172-2/+328
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * CMake 2.8.1v2.8.1Bill Hoffman2010-03-164-3/+8
| |
| * CMake 2.8.1-rc5Bill Hoffman2010-03-104-3/+21
| | | | | | | | | | | | | | 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
| * Increment RC number to RC 4 to match commits on branch.Bill Hoffman2010-03-051-1/+1
| |
| * CMake 2.8.1-rc4Brad King2010-03-058-8/+42
| | | | | | | | | | | | | | | | | | | | | | 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)
| * CMake 2.8.1-rc3Brad King2010-02-169-30/+79
| |
| * Fix rule hash persistence file generationBrad King2010-02-112-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * CMake 2.8.1-rc2Brad King2010-02-1133-115/+390
| |
| * Revert "Avoid CTest 2.6.4 dashboard script crash"Brad King2010-02-081-1/+0
| | | | | | | | | | The --force-new-ctest-process option does not do anything in the context where we added it, so we remove the useless change.
| * Avoid CTest 2.6.4 dashboard script crashBrad King2010-02-021-0/+1
| | | | | | | | | | | | | | | | | | 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.
| * Revert accidental CMake-2-8 branch commitBrad King2010-02-013-72/+0
| | | | | | | | | | Commit "Add alternate per-vendor compiler id detection" on this branch was meant for the main development line.
| * Add alternate per-vendor compiler id detectionBrad King2010-02-013-0/+72
| | | | | | | | | | | | | | 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.
| * CMake 2.8.1-rc1Brad King2010-01-28358-3143/+7287
| |
| * CMake 2.8.0v2.8.0Brad King2009-11-133-3/+20
| |
| * CMake 2.8.0-rc7Brad King2009-11-1124-53/+204
| |
| * CMake 2.8.0-rc6Brad King2009-11-106-24/+46
| |
| * Add missing depend on the branch to get release out as it does not really ↵Bill Hoffman2009-11-041-0/+2
| | | | | | | | affect the RC
| * CMake 2.8.0-rc5Brad King2009-11-0329-95/+325
| |
| * RC 4 mergeBill Hoffman2009-10-2897-681/+2658
| |
| * Merge in changes for RC 3Bill Hoffman2009-10-09118-778/+1666
| |
| * Merge in changes to CMake-2-8 RC 2Bill Hoffman2009-10-011002-11791/+12774
| |
| * Add change log and fix UMR in ctest from head.Bill Hoffman2009-09-252-0/+46
| |
| * Use cmake-gui.exe for add/remove icon.Bill Hoffman2009-09-251-0/+3
| |
| * Add RC value of 1Bill Hoffman2009-09-241-1/+1
| |
| * change version to RC 0Bill Hoffman2009-09-241-1/+2
| |
* | Merge branch 'version'Brad King2010-05-1716-89/+175
|\ \
| * | Package CMake with new version schemeBrad King2010-05-041-7/+2
| | |
| * | Report commit hash in CMake development versionsBrad King2010-04-234-3/+49
| | | | | | | | | | | | | | | | | | 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>".
| * | Teach CMake Policies about tweak version componentBrad King2010-04-233-29/+53
| | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | Teach cmake_minimum_required about tweak versionBrad King2010-04-232-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | The command now accepts four version components in the format major[.minor[.patch[.tweak]]] This corresponds to the new versioning scheme introduced recently.
| * | New version scheme to support branchy workflowBrad King2010-04-238-44/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v0.12 at 2024-12-28 20:45:22 (GMT)