summaryrefslogtreecommitdiffstats
path: root/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Begin post-2.8.3 developmentDavid Cole2010-11-031-2/+2
|
* CMake 2.8.3v2.8.3David Cole2010-11-031-1/+1
|
* CMake 2.8.3-rc4David Cole2010-10-291-1/+1
|
* CMake 2.8.3-rc3David Cole2010-10-201-1/+1
|
* CMake 2.8.3-rc2Brad King2010-10-061-1/+1
|
* Merge branch 'release'Brad King2010-10-061-3/+3
|\
| * CMake 2.8.3-rc1Brad King2010-09-151-3/+3
| |
* | Merge topic 'vs-project-groups'Brad King2010-10-051-7/+25
|\ \ | |/ |/| | | | | fd3249e New USE_FOLDERS property OFF by default. (#3796)
| * New USE_FOLDERS property OFF by default. (#3796)David Cole2010-10-021-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Visual Studio Express editions do not support solution folders, so default behavior should be as if USE_FOLDERS global property is OFF. Also, allow folder names to be the same as target names: internally, use a prefix to distinguish folder GUIDs from target GUIDs. Add a target and folder with the same name in the ExternalProject test to exercise this code. For CMake itself, provide a new option CMAKE_USE_FOLDERS that defaults to ON so that Visual Studio users get a nicely organized CMake project. Express edition users will have to turn off the CMAKE_USE_FOLDERS option in order to build CMake in the VS Express IDE.
* | Merge topic 'vs-project-groups'Brad King2010-09-081-1/+34
|\ \ | |/ | | | | | | e6ac0aa Add FOLDER target property, for IDEs (#3796)
| * Add FOLDER target property, for IDEs (#3796)David Cole2010-09-031-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This work was started from a patch by Thomas Schiffer. Thanks, Thomas! See the newly added documentation of the FOLDER target property for details. Also added global properties, USE_FOLDERS and PREDEFINED_TARGETS_FOLDER. See new docs here, too. By default, the FOLDER target property is used to organize targets into folders in IDEs that have support for such organization. This commit adds "solution folder" support to the Visual Studio generators. Currently works with versions 7 through 10. Also, use the new FOLDER property in the ExternalProject test and in the CMake project itself.
* | Add option CMAKE_USE_SYSTEM_LIBARCHIVE (#10923)Brad King2010-07-291-5/+20
| | | | | | | | | | Finish the implementation of the option from the skeleton left by the initial addition of libarchive.
* | Merge topic 'use-system-bzip2'Brad King2010-07-201-1/+4
|\ \ | | | | | | | | | | | | 6a24bdf Optionally use system bzip2 library (#10932)
| * | Optionally use system bzip2 library (#10932)Brad King2010-07-131-1/+4
| | | | | | | | | | | | | | | | | | | | | Add option CMAKE_USE_SYSTEM_BZIP2 and enable it automatically when CMAKE_USE_SYSTEM_LIBRARIES is on. While we're at it, remove XMLRPC from the list of system library options because we no longer provide it in source.
* | | Merge topic 'disable_gcc33_onfree_bsd'Brad King2010-07-131-1/+15
|\ \ \ | |/ / |/| | | | | | | | | | | 3ef273c Poison GCC 3.3 on OpenBSD a bit later 696a0af Disable gcc 33 on OpenBSD because it crashes CPack by default.
| * | Poison GCC 3.3 on OpenBSD a bit laterBrad King2010-07-061-16/+15
| | | | | | | | | | | | | | | | | | | | | Move lines from commit 696a0af (Disable gcc 33 on OpenBSD because it crashes CPack by default, 2010-06-25) further down in CMakeLists.txt so that CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS applies. This fixes the code for building with CMake 2.4.
| * | Disable gcc 33 on OpenBSD because it crashes CPack by default.Bill Hoffman2010-06-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | Make sure no one tries to use gcc 33 based tools to build CMake. This is because a cpack test failed with a crash. The crash seems to be caused by the stack checking code on by default in OpenBSD. The crash is in some stl code. The problem is fixed with newer gcc compilers on OpenBSD.
* | | Begin post-2.8.2 developmentBrad King2010-06-281-2/+2
| | |
* | | CMake 2.8.2v2.8.2Brad King2010-06-281-1/+1
| |/ |/|
* | CMake 2.8.2-rc4Brad King2010-06-241-1/+1
| |
* | CMake 2.8.2-rc3Brad King2010-06-221-1/+1
| |
* | CMake 2.8.2-rc2Brad King2010-06-151-1/+1
| |
* | Merge branch 'release'Brad King2010-06-151-3/+3
|\ \ | |/ |/|
| * CMake 2.8.2-rc1Brad King2010-06-111-3/+3
| |
* | Merge branch 'make_libarchive_use_cmzlib'Brad King2010-06-151-0/+1
|\ \
| * | Make sure libarchive uses cmzlib and not the system libz if found.Bill Hoffman2010-06-111-0/+1
| |/
* | Fix CMake data and doc paths in Cygwin packageBrad King2010-06-091-0/+11
|/ | | | | | | Override CMAKE_DOC_DIR and CMAKE_DATA_DIR cache entries on Cygwin early enough so the new values are used everywhere. Previously only some of the uses were overridden. Also set CPACK_PACKAGE_VERSION to the whole CMake_VERSION so that the Cygwin MANIFEST file goes in the proper path.
* Merge CMake 2.8.1 to start branchy workflowBrad King2010-05-171-2/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-161-1/+1
| |
| * CMake 2.8.1-rc5Bill Hoffman2010-03-101-1/+1
| | | | | | | | | | | | | | 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-rc3Brad King2010-02-161-1/+1
| |
| * CMake 2.8.1-rc2Brad King2010-02-111-1/+1
| |
| * CMake 2.8.1-rc1Brad King2010-01-281-17/+43
| |
| * CMake 2.8.0v2.8.0Brad King2009-11-131-1/+1
| |
| * CMake 2.8.0-rc7Brad King2009-11-111-1/+1
| |
| * CMake 2.8.0-rc6Brad King2009-11-101-1/+1
| |
| * CMake 2.8.0-rc5Brad King2009-11-031-1/+1
| |
| * RC 4 mergeBill Hoffman2009-10-281-2/+3
| |
| * Merge in changes for RC 3Bill Hoffman2009-10-091-4/+4
| |
| * Merge in changes to CMake-2-8 RC 2Bill Hoffman2009-10-011-1/+17
| |
| * Add RC value of 1Bill Hoffman2009-09-241-1/+1
| |
| * change version to RC 0Bill Hoffman2009-09-241-1/+2
| |
* | Report commit hash in CMake development versionsBrad King2010-04-231-0/+6
| | | | | | | | | | | | 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>".
* | New version scheme to support branchy workflowBrad King2010-04-231-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Add CMAKE_TESTS_CDASH_SERVER variable and CTestSubmitLargeOutput test.David Cole2010-03-081-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If defined and non-empty, the value of CMAKE_TESTS_CDASH_SERVER should point to a CDash server willing to accept submissions for a project named PublicDashboard. On machines that also run a CDash dashboard, set this variable to "http://localhost/CDash-trunk-Testing" so that the CMake tests that submit dashboards do not have to send those submissions over the wire. The CTestSubmitLargeOutput test runs a dashboard that has a test that produces very large amount of output on stdout/stderr. Since we do not even want to attempt to send such large output over the wire, this test is off by default unless the CMAKE_TESTS_CDASH_SERVER server is localhost. This test is expected to cause a submission failure when sent to CDash. It passes if the submit results contain error output. It fails if the submit succeeds. CMAKE_TESTS_CDASH_SERVER: CDash server used by CMake/Tests. If not defined or "", this variable defaults to the server at http://www.cdash.org/CDash. If set explicitly to "NOTFOUND", curl tests and ctest tests that use the network are skipped. If set to something starting with "http://localhost/", the CDash is expected to be an instance of CDash used for CDash testing, pointing to a cdash4simpletest database. In these cases, the CDash dashboards should be run first.
* | Disable arch-specific try_run in CMake itselfBrad King2009-12-141-0/+11
| | | | | | | | | | | | | | We disallow try_run() when CMAKE_TRY_COMPILE_OSX_ARCHITECTURES is set because the binary might not be able to run on the host architecture. This prevents us from creating ppc test binaries on i386 Mac machines that cause Rosetta install dialogs to appear.
* | Test 'install' target of CMake itselfBrad King2009-12-101-0/+4
| | | | | | | | | | | | We create option CMake_TEST_INSTALL to enable a new CMake.Install test. It tests running the "make install" target to install CMake itself into a test directory. We enable the option by default for dashboard builds.
* | Apply CMake test-time config to all testsBrad King2009-12-101-0/+4
| | | | | | | | | | | | We configure an EnforceConfig.cmake script to load at CTest time. Previously we loaded it from Tests/CTestTestfile.cmake, but now we load it from the top level so it applies to all tests.
* | Fix installation of CMake itselfBrad King2009-12-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake 2.8.0 and below use the EXECUTABLE_OUTPUT_PATH setting from the top-level CMakeLists.txt file to compute the location of the "cmake" target for the special case of installing cmake over itself. The commit "Clean up CMake build tree 'bin' directory" moved the setting of EXECUTABLE_OUTPUT_PATH that affects the "cmake" target into the Source subdirectory. This broke the special-case lookup in the top level. We fix it by setting EXECUTABLE_OUTPUT_PATH at the end of the top-level CMakeLists.txt file. Now that we use add_subdirectory to process the subdirectories in order, this setting does not affect the subdirectories. Thus we fix installation while preserving the clean build tree 'bin' directory intended by the above-mentioned commit.