https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Brad.king&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T05:36:34ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=VTK/Building/Linux&diff=63989VTK/Building/Linux2019-12-12T19:58:40Z<p>Brad.king: /* Download */</p>
<hr />
<div>== Download ==<br />
Download the source code from the [https://vtk.org/download/ VTK Download page] or [[VTK/Git | Clone with Git]]<br />
git clone https://gitlab.kitware.com/vtk/vtk.git VTK<br />
<br />
== Configure ==<br />
Create a build directory which is separate from the source. <br />
mkdir VTK-build<br />
cd VTK-build<br />
ccmake /path/to/VTK<br />
<br />
Set any options you would like using the curses interface. Alternatively, set the options at the command line.<br />
<br />
mkdir VTK-Release-build<br />
cd VTK-Release-build<br />
cmake -DCMAKE_BUILD_TYPE:STRING=Release /path/to/VTK<br />
<br />
=== Qt Setup ===<br />
<br />
==== Qt5 ====<br />
In order to build with the latest Qt5 release (Qt5.2.1), take the following steps:<br />
* Download the [http://download.qt-project.org/official_releases/qt/5.2/5.2.1/qt-opensource-linux-x64-5.2.1.run Qt.5.2.1 offline installer for linux] and run it<br />
mkdir qt5.2.1-install && cd qt5.2.1-install<br />
wget http://download.qt-project.org/official_releases/qt/5.2/5.2.1/qt-opensource-linux-x64-5.2.1.run<br />
chmod +x qt-opensource-linux-x64-5.2.1.run<br />
./qt-opensource-linux-x64-5.2.1.run<br />
* Install to a separate directory<br />
* Configure VTK with the following options<br />
cd /path/to/VTK-Release-build<br />
cmake -DVTK_QT_VERSION:STRING=5 \<br />
-DQT_QMAKE_EXECUTABLE:PATH=/path/to/qt5.2.1-install/5.2.1/gcc_64/bin/qmake \<br />
-DVTK_Group_Qt:BOOL=ON \<br />
-DCMAKE_PREFIX_PATH:PATH=/path/to/qt.5.2.1-install/5.2.1/gcc_64/lib/cmake \<br />
-DBUILD_SHARED_LIBS:BOOL=ON<br />
/path/to/VTK<br />
<br />
==== Qt4 ====<br />
* The latest patch release (Qt4.8.6) does not appear to have an installer for linux on the [http://qt-project.org/downloads Qt Downloads page] so the code must be built from source.<br />
mkdir qt-4.8.6-build && cd qt-4.8.6-build<br />
wget http://download.qt-project.org/official_releases/qt/4.8/4.8.6/qt-everywhere-opensource-src-4.8.6.tar.gz<br />
tar xzf qt-everywhere-opensource-src-4.8.6.tar.gz<br />
cd qt-everywhere-opensource-src-4.8.6<br />
./configure # go through the dialogue <br />
make -j<# of cores><br />
* Then in the VTK build directory, configure VTK with the path to the Qt build<br />
cmake -DQT_QMAKE_EXECUTABLE:PATH=/path/to/qt-4.8.6-build/qt-everywhere-opensource-src-4.8.6/bin/qmake \<br />
-DVTK_Group_Qt:BOOL=ON \<br />
-DBUILD_SHARED_LIBRARIES:BOOL=ON \<br />
/path/to/VTK<br />
<br />
== Build ==<br />
Once cmake finishes successfully configuring, use make inside the build directory.<br />
<br />
make -j<# of cores></div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake/GSoC&diff=62672CMake/GSoC2018-04-30T12:53:13Z<p>Brad.king: Remove extra newline</p>
<hr />
<div><br />
Project ideas for the Google Summer of Code 2011<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.cmake.org/ CMake]. If you wish to submit a proposal based on these ideas you may wish to contact the developers to find out more about the idea you are looking at, get to know the developers your proposal will be reviewed by and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors and possibly have submitted a patch or two to fix bugs in the project they intend to work. Kitware makes extensive use of mailing lists, and this would be your best point of initial contact for any of the proposed projects you would like to apply for. The mailing lists can be found on the project pages linked to in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea.<br />
* Expected results/feature additions.<br />
* Any prerequisites for working on the project.<br />
* Links to any further information, discussions, bug reports etc.<br />
* Any special mailing lists if not the standard mailing list for the CMake.<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor).<br />
<br />
If you are not a developer for the project concerned, please contact a developer about the idea before adding it here.<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.cmake.org/ Project page], [http://www.cmake.org/cmake/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=CMake dashboard].<br />
<br />
=== Project: CMake Autoconf Compatibility ===<br />
<br />
'''Brief explanation:''' One of the things that prevents some projects from migrating to CMake is their current investment and shared knowledge of the auto* family of tools. Creating improved compatibility functions matching the familiar auto* syntax for things like header checks, command line switches to cmake etc would improve this situation significantly. The student would need to assess syntax that should be replicated in both the CMake language, and common command line switches such as --prefix=... Some modules already exist that implement some of this functionality, and these could be used as a starting point.<br />
<br />
'''Expected results:''' Improved implementation of auto* like syntax to aid projects when migrating their build systems over to CMake. Additional documentation on the migration process, and working with existing communities that have needs in this area.<br />
<br />
'''Mentor:''' Bill Hoffman (bill dot hoffman at kitware dot com).<br />
<br />
=== Project: CMake Project Generator ===<br />
<br />
'''Brief explanation:''' The addition of a facility in CMake to automatically generate CMakeLists files based upon the source files present in a directory. So a developer can point CMake at a directory full of source files with a '--generate-project' argument for example, and automatically generate a project. This should detect if source files contain the QOBJECT macro, and need Qt's moc running on them, adding them to the appropriate CMake variable. This would be limited in scope to relatively simple projects wanting a single executable to be built from the source files, with some heuristics or switches to determine what toolkit etc it being used.<br />
<br />
'''Expected results:''' A new facility added to the CMake suite of tools to generate simple CMakeLists files when supplied the path to a source directory. The user should reasonably expect to be able to run generate CMakeLists files, run CMake on these files and type make to build their project. Similar in functionality to the feature provided by qmake.<br />
<br />
'''Prerequisites:''' Some familiarity with CMake, C++ and Qt.<br />
<br />
'''Mentor:''' Marcus Hanwell (marcus dot hanwell at kitware dot com).<br />
<br />
=== Project: CMake ninja generator ===<br />
<br />
'''Brief explanation:''' CMake supports regular makefiles, and IDE's for all versions of Visual Studio, and Xcode. However, the new tool Ninja http://martine.github.com/ninja/manual.html has some properties that might allow faster builds over traditional makefiles. The idea of this project would be to create a new backend build tool format for CMake.<br />
<br />
'''Expected results:''' A new option for any project using CMake to build with the Ninja tool.<br />
<br />
'''Prerequisites:''' Experience with C++ programming, and a working knowledge of build tools like make.<br />
<br />
'''Mentor:''' Bill Hoffman.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMakeUserUseLATEX_UseLATEX.cmake&diff=62671CMakeUserUseLATEX UseLATEX.cmake2018-04-30T12:34:56Z<p>Brad.king: </p>
<hr />
<div>{{CMake/Template/Moved}}<br />
<br />
This page has moved [https://gitlab.kitware.com/cmake/community/wikis/contrib/modules/UseLATEX here].</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=Template:CMake/Template/Moved&diff=62670Template:CMake/Template/Moved2018-04-30T12:30:15Z<p>Brad.king: Created page with "Category:CMake The CMake community Wiki has moved to the [https://gitlab.kitware.com/cmake/community/wikis/home Kitware GitLab Instance]."</p>
<hr />
<div>[[Category:CMake]]<br />
<br />
The CMake community Wiki has moved to the [https://gitlab.kitware.com/cmake/community/wikis/home Kitware GitLab Instance].</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake/ChangeLog&diff=62669CMake/ChangeLog2018-04-30T12:11:57Z<p>Brad.king: </p>
<hr />
<div>See https://cmake.org/cmake/help/latest/release/index.html</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62668CMake2018-04-27T14:59:49Z<p>Brad.king: /* More Information */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake:How_To_Write_Platform_Checks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake/Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving_Find*_Modules]]<br />
* [[CMake/C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest/Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62667CMake2018-04-27T14:34:26Z<p>Brad.king: /* Development Topics */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake:How_To_Write_Platform_Checks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake/Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving_Find*_Modules]]<br />
* [[CMake/C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62666CMake2018-04-27T14:33:50Z<p>Brad.king: /* General */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake:How_To_Write_Platform_Checks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake/Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving_Find*_Modules]]<br />
* [[CMake/C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake_FAQ&diff=62665CMake FAQ2018-04-27T14:32:10Z<p>Brad.king: /* How to have backward and forward compatibility? */</p>
<hr />
<div>== General information and availability ==<br />
=== What is CMake? ===<br />
CMake is a cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform-independent and compiler-independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, preprocessor generation, code generation, and template instantiation. Please go to http://www.cmake.org/overview to learn more about CMake.<br />
<br />
=== What is the current release? ===<br />
The latest release of CMake is always available at: http://www.cmake.org/download<br />
<br />
From there, you can fetch CMake binaries for Windows or several Unix variants, or you can download the source code of CMake.<br />
<br />
You can also access nightly development through Git; see http://www.cmake.org/download for more information. You may also browse the [http://cmake.org/gitweb?p=cmake.git git repository online].<br />
<br />
=== I found a Bug! What should I do? ===<br />
If you have a patch to contribute, please read [http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master CONTRIBUTING.rst] at the top of the CMake source tree.<br />
<br />
Otherwise, please report the bug in our bug tracker: http://www.cmake.org/Bug<br />
<br />
Please make sure to look at the old bugs not to include duplicates, include detailed instructions of the bug and how to reproduce it.<br />
<br />
=== I want a new feature in CMake. What should I do? ===<br />
Report a feature request in our Bug tracker http://www.cmake.org/Bug<br />
<br />
Please make sure to look at the old feature requests not to include duplicates, include detailed instructions of the feature and proposed implementation.<br />
<br />
=== What is the most recent version covered by the Mastering CMake book? ===<br />
A new edition of the [http://www.kitware.com/products/cmakebook.html Mastering CMake] book has been released which documents CMake 2.6.<br />
<br />
The following features have been added since printing the book:<br />
<br />
* New INSTALL command (cmake --help-command INSTALL)<br />
* New LIST command (cmake --help-command LIST)<br />
* Updated FIND_PATH, FIND_PROGRAM, and FIND_FILE commands to be more powerful (cmake --help-command FIND_PATH)<br />
* RPATH and Mac OS X install_name support (cmake --help-command SET_TARGET_PROPERTIES)<br />
* CPack Beta (not finished or documented)<br />
* EXECUTE_PROCESS was added and replaces EXEC_PROGRAM<br />
* Other changes have been bug fixes and internal CMake restructuring<br />
<br />
=== Where can I find searchable CMake Mailing Archives? ===<br />
There exist at least these ones:<br />
* [http://dir.gmane.org/gmane.comp.programming.tools.cmake.user cmake on Gmane]<br />
* [http://www.mail-archive.com/cmake@cmake.org/ http://www.mail-archive.com/cmake@cmake.org/]<br />
* [http://marc.info/?l=cmake http://marc.info/?l=cmake]<br />
* Use google ''site'' keyword in order to search directly in the CMake browsable ML:<br />
<pre><br />
site:http://www.cmake.org/pipermail/cmake/ <search terms><br />
</pre><br />
<br />
== Running CMake ==<br />
<br />
=== Is there an option to produce more 'verbose' compiling? ===<br />
<br />
On Makefile generators, you can set the Makefile variable VERBOSE to 1. For example on UNIX:<br />
<pre><br />
make VERBOSE=1<br />
</pre><br />
<br />
You can also set CMAKE_VERBOSE_MAKEFILE to ON.<br />
<br />
On Windows (nmake) you can override CMAKE_VERBOSE_MAKEFILE by using<br />
<pre><br />
nmake /S<br />
</pre><br />
On Unix make you can mostly override verbose mode by using<br />
<pre><br />
make VERBOSE=""<br />
</pre><br />
<br />
If you are on Windows using Borland or NMake Makefiles, you will see lines like:<br />
<br />
<pre><br />
cl @c:\DOCUME~1\ANDY~1.KIT\LOCALS~1\Temp\nma03504<br />
</pre><br />
<br />
The reason for this is that Borland and Microsoft Visual Studio make programs have limitation on the length of command strings. They overcome this limitation by writing arguments to the file and then pass file to the program.<br />
<br />
If you actually want to see what the command looks like, set CMAKE_START_TEMP_FILE and CMAKE_END_TEMP_FILE to "" -- be warned, however, you cannot set these as variables on the CMake command line with -D. Instead, see the very bottom of the file "Modules/Platform/Windows.cmake" and uncomment the lines that set these variables to the empty string.<br />
<br />
=== Is there a way to skip checking of dependent libraries when compiling? ===<br />
<br />
'''Using the Makefile Generator'''<br />
<br />
When using the Makefile generator under *nix you can append "/fast" to your target name. For example:<br />
<br />
<pre><br />
make target_name/fast<br />
</pre><br />
<br />
Under Windows use a backslash instead:<br />
<br />
<pre><br />
make target_name\fast<br />
</pre><br />
<br />
Be aware that this can cause link errors if the targets that were skipped are not actually built. Use it only if you know what you're doing!<br />
<br />
'''Using Visual Studio >= 7.1'''<br />
<br />
If you have Visual Studio .NET 7.1 or greater you can use the native option to right click on a project and choose to build just that project.<br />
<br />
'''Using Visual Studio <= 7.0'''<br />
<br />
CMake doesn't try to compile all dependent libraries when you compile a library but it will do so for binary targets. You can't avoid this however you can take advantage of CTRL+F7 to manually compile a source file for the affected target and then relink the target by right clicking on it and choosing Link. You'll have to ensure that all dependent libraries are made up-to-date however or suffer through Visual's slow check.<br />
<br />
=== I set a cmake variable in my environment, but it didn't change anything. Why? ===<br />
CMake build settings are stored in the CMake cache corresponding to a project's build tree. They are called CMake "cache entries" and have no relation to your command shell's environment variables. Use a CMake GUI (CMakeSetup on Windows or ccmake on UNIX) or the wizard mode (cmake -i) to edit cache entries. Initial values may also be specified for a build by using the -D command line argument to cmake when it is first run to produce a new build tree.<br />
<br />
=== How do I use a different compiler? ===<br />
<br />
==== Method 1: use environment variables ====<br />
<br />
For C and C++, set the <tt>CC</tt> and <tt>CXX</tt> environment<br />
variables. This method is not guaranteed to work for all generators.<br />
(Specifically, if you are trying to set Xcode's <tt>GCC_VERSION</tt>,<br />
this method confuses Xcode.)<br />
<br />
For example:<br />
<pre><br />
CC=gcc-4.2 CXX=/usr/bin/g++-4.2 cmake -G "Your Generator" path/to/your/source<br />
</pre><br />
<br />
==== Method 2: use cmake -D ====<br />
<br />
Set the appropriate <tt>CMAKE_FOO_COMPILER</tt> variable(s) to a valid<br />
compiler name or full path on the command-line using <tt>cmake -D</tt>.<br />
<br />
For example:<br />
<pre><br />
cmake -G "Your Generator" -D CMAKE_C_COMPILER=gcc-4.2 -D CMAKE_CXX_COMPILER=g++-4.2 path/to/your/source<br />
</pre><br />
<br />
==== Method 3 (avoid): use set() ====<br />
<br />
Set the appropriate <tt>CMAKE_FOO_COMPILER</tt> variable(s) to a valid<br />
compiler name or full path in a list file using <tt>set()</tt>. This<br />
must be done ''before'' any language is set (ie before any<br />
<tt>project()</tt> or <tt>enable_language()</tt> command).<br />
<br />
For example:<br />
<pre><br />
set(CMAKE_C_COMPILER "gcc-4.2")<br />
set(CMAKE_CXX_COMPILER "/usr/bin/g++-4.2")<br />
<br />
project("YourProjectName")<br />
</pre><br />
<br />
=== I change CMAKE_C_COMPILER in the GUI but it changes back on the next configure step. Why? ===<br />
<br />
Once a build tree is created with a given compiler it cannot be changed. There are a variety of implementation reasons for this policy.<br />
<br />
=== In CCMake, typing full paths is tedious. Is there a better way? ===<br />
Since CMake 1.6, you can use tab completion in the path entries in CCMake. All you do is type first couple of characters and press <TAB> key. CCMake will examine the current typed path and try to expand it to some existing path. If that is possible, it will do it. If not, it will not do anything.<br />
<br />
For example:<br />
<br />
<pre><br />
/usr/loc<TAB><br />
</pre><br />
<br />
will expand to<br />
<br />
<pre><br />
/usr/local/<br />
</pre><br />
<br />
<br />
<br />
== Out-of-source build trees ==<br />
<br />
=== What is an "out-of-source" build? ===<br />
When your build generates files, they have to go somewhere. An in-source build puts them in your source tree. An out-of-source build puts them in a completely separate directory, so that your source tree is unchanged.<br />
<br />
In the first example, an in-place build is performed, i.e., the binaries are placed in the same directory as the source code.<br />
<br />
<pre><br />
cd Hello<br />
ccmake .<br />
make<br />
</pre><br />
<br />
In the second example, an out-of-place build is performed, i.e., the source code, libraries, and executables are produced in a directory separate from the source code directory(ies).<br />
<br />
<pre><br />
mkdir HelloBuild<br />
cd HelloBuild<br />
ccmake ../Hello<br />
make<br />
</pre><br />
<br />
Out-of-source builds are recommended, as you can build multiple variants in separate directories, e.g., HelloBuildDebug, HelloBuildRelease.<br />
<br />
Note: Before performing an out-of-source build, ensure that all CMake generated in-source build information is removed from the source directory, e.g., CMakeFiles directory, CMakeCache.txt.<br />
<br />
=== I run an out-of-source build but CMake generates in-source anyway. Why? ===<br />
This means that there is a CMakeCache.txt file in the source tree, possibly as part of an existing in-source build. If CMake is given the path to a directory with a CMakeCache.txt file, it assumes the directory is a build tree. Therefore if one runs "cmake ../mysrc" to build out-of-source but there is a mysrc/CMakeCache.txt file then cmake will treat mysrc as the build tree.<br />
<br />
This is a side-effect of the feature that allows "cmake ." to be used to regenerate a build tree. The behavior will not be changed because mixing in-source and out-of-source builds is not safe anyway (configured headers may be found in the wrong place).<br />
<br />
=== Why does CMake use full paths, or can I copy my build tree? ===<br />
CMake uses full paths because:<br />
<br />
# configured header files may have full paths in them, and moving those files without re-configuring would cause upredictable behavior.<br />
# because cmake supports out of source builds, if custom commands used relative paths to the source tree, they would not work when they are run in the build tree because the current directory would be incorrect.<br />
# on Unix systems rpaths might be built into executables so they can find shared libraries at run time. If the build tree is moved old executables may use the old shared libraries, and not the new ones.<br />
<br />
Can the build tree be copied or moved?<br />
<br />
The short answer is NO. The reason is because full paths are used in CMake, see above. The main problem is that cmake would need to detect when the binary tree has been moved and rerun. Often when people want to move a binary tree it is so that they can distribute it to other users who may not have cmake in which case this would not work even if cmake would detect the move.<br />
<br />
The workaround is to create a new build tree without copying or moving the old one.<br />
<br />
<br />
=== CMake does not generate a "make distclean" target. Why? ===<br />
Some build trees created with GNU autotools have a "make distclean" target that cleans the build and also removes Makefiles and other parts of the generated build system. CMake does not generate a "make distclean" target because CMakeLists.txt files can run scripts and arbitrary commands; CMake has no way of tracking exactly which files are generated as part of running CMake. Providing a distclean target would give users the false impression that it would work as expected. (CMake does generate a "make clean" target to remove files generated by the compiler and linker.)<br />
<br />
A "make distclean" target is only necessary if the user performs an in-source build. CMake supports in-source builds, but we strongly encourage users to adopt the notion of an out-of-source build. Using a build tree that is separate from the source tree will prevent CMake from generating any files in the source tree. Because CMake does not change the source tree, there is no need for a distclean target. One can start a fresh build by deleting the build tree or creating a separate build tree.<br />
<br />
(If a CMakeLists.txt uses ADD_CUSTOM_COMMAND to generate source files in the source tree, not the build tree, then in CMake 2.2 or higher "make clean" will remove them. See next question.)<br />
<br />
=== Running "make clean" does not remove custom command outputs. Why? ===<br />
In CMake 2.2 and higher custom command outputs should be removed by make clean. Make sure you are using at least this version. Prior to CMake 2.2 custom command outputs were not automatically added to the list of files to clean. In CMake 2.0 the developer can specify a list of files to be deleted. This can be done using SET_DIRECTORY_PROPERTIES setting property ADDITIONAL_MAKE_CLEAN_FILES to the list of files.<br />
<br />
We however strongly recommend using an "out-of-source" build which never writes any files to the source tree. Using a separate source and build tree greatly reduces the need for "make clean" and "make distclean" targets to clean away files that differ between builds.<br />
<br />
<br />
== Writing CMakeLists.txt ==<br />
<br />
=== How to have backward and forward compatibility? ===<br />
<br />
As of CMake 2.6 we employ a "Policy" mechanism to provide backwards compatibility.<br />
The basic requirement for projects is to include one line at the top of the highest CMakeLists.txt file:<br />
<br />
<pre><br />
cmake_minimum_required(VERSION 2.6) # or other version<br />
</pre><br />
<br />
This tells versions of CMake older than that specified that they are too old to build the project.<br />
They will report this information to the user.<br />
It also tells versions of CMake newer than that specified that the project may not be aware of policies introduced in later versions, which enables additional compatibility.<br />
For futher documentation, see<br />
<br />
* [[CMake/Policies|CMake Policy Mechanism]]<br />
* [http://www.cmake.org/cmake/help/cmake2.6docs.html#command:cmake_policy cmake_policy() command]<br />
* [http://www.cmake.org/cmake/help/cmake2.6docs.html#section_Policies CMake 2.6 Policies]<br />
<br />
=== How do I get the current source or binary directory? ===<br />
The variable CMAKE_CURRENT_SOURCE_DIR contains the absolute path to your current source directory, while CMAKE_CURRENT_BINARY_DIR points to the equivalent binary directory.<br />
<br />
=== Why are my CMake variables not updated in the GUI after a SET command? ===<br />
The cache variables listed in the GUI when you press "Configure" are used to initialize the values seen by the code in CMakeLists.txt files.<br />
<br />
Changes made by the code are used during the configure step and seen by the generators but are not stored back into the cache. For example:<br />
<br />
<pre><br />
SET(BUILD_SHARED_LIBS ON)<br />
</pre><br />
<br />
will turn on building of shared libraries for the directory containing the command and all subdirectories, but the change will not appear in the GUI.<br />
<br />
You can use the CACHE and FORCE options on the SET command to change variables in a way that will be reflected in the GUI. Run<br />
<br />
<pre><br />
cmake --help-command SET<br />
</pre><br />
<br />
to see full instructions for the command.<br />
<br />
<br />
=== How can I change the default build mode and see it reflected in the GUI? ===<br />
Adapt the following commands in your CMakeLists.txt (this example sets the Release<br />
With Debug Information mode):<br />
<pre><br />
IF(NOT CMAKE_BUILD_TYPE)<br />
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING<br />
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel."<br />
FORCE)<br />
ENDIF(NOT CMAKE_BUILD_TYPE)<br />
</pre><br />
<br />
=== How do I generate an executable, then use the executable to generate a file? ===<br />
<br />
Create the generator executable by just adding a target:<br />
<br />
<pre><br />
ADD_EXECUTABLE(generate generate.c)<br />
</pre><br />
<br />
The rest of the process is simpler in CMake 2.6 and above than in previous versions.<br />
<br />
Use <code>ADD_CUSTOM_COMMAND</code> to specify a custom build rule for the file.<br />
(In this example we assume <code>generate</code> accepts the input and output files as arguments.)<br />
<br />
<pre><br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT someoutput.txt<br />
COMMAND generate ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt<br />
DEPENDS generate ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt<br />
)<br />
</pre><br />
<br />
This tells CMake how to build the file but does not actually add a rule to the build system.<br />
Another target must require it.<br />
One may create a custom target explicitly for this rule:<br />
<br />
<pre><br />
ADD_CUSTOM_TARGET(driver ALL DEPENDS someoutput.txt)<br />
</pre><br />
<br />
or the file may be added as part of some other target:<br />
<br />
<pre><br />
ADD_EXECUTABLE(product product.c someoutput.txt)<br />
</pre><br />
<br />
<font color=#555555><br />
In CMake 2.4 and below the <code>generate</code> target may not be specified directly in the <code>COMMAND</code> option of <code>add_custom_command</code><br />
(but it can still be used in the <code>DEPENDS</code> option as of CMake 2.4).<br />
Instead use GET_TARGET_PROPERTY to obtain the location of the generated executable.<br />
Additionally, the output must always be specified by full path.<br />
<br />
<pre><br />
GET_TARGET_PROPERTY(GENERATE_EXE generate LOCATION)<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt<br />
COMMAND ${GENERATE_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt<br />
DEPENDS generate<br />
)<br />
</pre><br />
</font><br />
<br />
=== How can I generate a source file during the build? ===<br />
The ADD_CUSTOM_COMMAND command lets you generate a source file that you can then include in another target. For example:<br />
<br />
<pre><br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c<br />
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c<br />
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c<br />
)<br />
ADD_EXECUTABLE(foo foo.c)<br />
</pre><br />
<br />
This will create an executable by copying bar.c to foo.c and then compiling foo.c to produce foo. CMake allows you to put generated source files in the current source or binary directory, so we were careful to output foo.c to the current binary directory. When we add foo.c to foo, CMake will look in either directory for it. Even if foo.c does not yet exist, CMake is smart enough to notice that a custom command creates it. (For the file named as the OUTPUT, CMake has its GENERATED source file property set to true.)<br />
<br />
You can also use ADD_CUSTOM_COMMAND when the<br />
[[CMake_FAQ#How_do_I_generate_an_executable.2C_then_use_the_executable_to_generate_a_file.3F|generator command is another executable in the same project]].<br />
<br />
Sometimes, the program doing the generation may generate multiple output files that each need to be part of the build. CMake 2.4 or higher supports having multiple files listed in the OUTPUT section. For example, suppose you had a program that read input.txt and generated three files output1.cpp, output2.h, and output3.cpp, and that those three files needed to be compiled into an executable program. The cmake list file for that would look like this:<br />
<br />
<pre><br />
PROJECT(FOO)<br />
# make sure cmake addes the binary directory for the project to the include path<br />
INCLUDE_DIRECTORIES(${FOO_BINARY_DIR})<br />
# add the executable that will do the generation<br />
ADD_EXECUTABLE(my_generator my_generator.cxx)<br />
GET_TARGET_PROPERTY(MY_GENERATOR_EXE my_generator LOCATION)<br />
# add the custom command that will generate all three files<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${FOO_BINARY_DIR}/output1.cpp ${FOO_BINARY_DIR}/output2.h ${FOO_BINARY_DIR}/output3.cpp<br />
COMMAND ${MY_GENERATOR_EXE} ${FOO_BINARY_DIR} ${FOO_SOURCE_DIR}/input.txt<br />
DEPENDS my_generator<br />
MAIN_DEPENDENCY ${FOO_SOURCE_DIR}/input.txt<br />
)<br />
# now create an executable using the generated files<br />
ADD_EXECUTABLE(generated<br />
${FOO_BINARY_DIR}/output1.cpp<br />
${FOO_BINARY_DIR}/output2.h<br />
${FOO_BINARY_DIR}/output3.cpp)<br />
</pre><br />
<br />
CMake 2.4 allows you to generate a header file. Because generated headers often cause unnecessary rebuilds, you should try to avoid them; consider using the CONFIGURE_FILE command to prepare the header at CMake time. If you must generate a header file, use code like this:<br />
<br />
<pre><br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.h<br />
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.h ${CMAKE_CURRENT_BINARY_DIR}/foo.h<br />
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.h<br />
)<br />
ADD_EXECUTABLE(foo foo.c ${CMAKE_CURRENT_BINARY_DIR}/foo.h)<br />
</pre><br />
<br />
This is like the first example above, except that it generates a header instead of a C file. The header might not exist when the build system scans foo.c's dependencies, so there is no way for CMake to know that this target requires foo.h unless we can tell it that foo.h may exist in the future. We give CMake this knowledge by listing the generated header file in the set of source files for the target. (This requires CMake 2.4. Previous versions of CMake required use of the OBJECT_DEPENDS source file property.)<br />
<br />
=== How can I add a dependency to a source file which is generated in a subdirectory? ===<br />
<br />
Rules created with <code>ADD_CUSTOM_COMMAND</code> as [[CMake_FAQ#How_can_I_generate_a_source_file_during_the_build.3F|above]] have scope only in the directory in which they are specified.<br />
If the generated file is needed in another directory, a target-level dependency needs to be added.<br />
Create a target in the subdirectory with the custom rule in order to drive it:<br />
<br />
<pre><br />
# subdir/CMakeLists.txt<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c<br />
COMMAND ${CMAKE_COMMAND} copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c<br />
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c<br />
)<br />
ADD_CUSTOM_TARGET(generate_foo DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.c)<br />
</pre><br />
<br />
Now other targets can depend on the target from the subdirectory:<br />
<br />
<pre><br />
# CMakeLists.txt<br />
ADD_SUBDIRECTORY(subdir)<br />
# Create the executable.<br />
ADD_EXECUTABLE(generated ${CMAKE_CURRENT_BINARY_DIR}/subdir/foo.c)<br />
# Tell CMake the source won't be available until build time.<br />
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_BINARY_DIR}/subdir/foo.c PROPERTIES GENERATED 1)<br />
# Make sure the source is generated before the executable builds.<br />
ADD_DEPENDENCIES(generated generate_foo)<br />
</pre><br />
<br />
=== How can I generate a file used in more than one target in the same directory? ===<br />
<br />
CMake will generate a copy of a custom command in the build rules for every target that lists the custom command output as a source file.<br />
There is no other place to put it.<br />
If a single custom command output is listed in more than one target and the targets have no dependency relationship they will race to run the custom command during a parallel build and possibly clobber each other.<br />
For example:<br />
<br />
<pre><br />
add_custom_command(OUTPUT Foo.c COMMAND ... DEPENDS ...)<br />
add_library(FooStatic STATIC Foo.c)<br />
add_library(FooShared SHARED Foo.c)<br />
</pre><br />
<br />
There are at least two solutions to this problem.<br />
First, one may use add_dependencies to serialize the targets involved:<br />
<br />
<pre><br />
add_dependencies(FooShared FooStatic)<br />
</pre><br />
<br />
Second, one may add a custom target dedicated to generating files for the other targets:<br />
<br />
<pre><br />
add_custom_target(Foo DEPENDS Foo.c)<br />
add_dependencies(FooStatic Foo)<br />
add_dependencies(FooShared Foo)<br />
</pre><br />
<br />
The latter solution ensures that generated files are up to date before any of the independent targets build so none of them will run the custom command and there will be no race.<br />
<br />
=== I use EXEC_PROGRAM but the result is not set in subdirectories. Why? ===<br />
<br />
An unfortunate holdover from ancient CMake versions is that certain commands are "inherited" into subdirectories and others are not. EXEC_PROGRAM is not inherited. What this means is that when the listfile code from a parent directory executes in a subdirectory the EXEC_PROGRAM command is left out. Therefore the code executes differently. This problem was fixed in CMake 2.2, but for older versions you will have to cache the result:<br />
<br />
<pre><br />
EXEC_PROGRAM(my-program OUTPUT_VARIABLE MY_OUTPUT)<br />
SET(MY_OUTPUT "${MY_OUTPUT}" CACHE INTERNAL "")<br />
</pre><br />
<br />
This will store the result in a global location so it will be available in the subdirectory. Be sure to choose a descriptive name for MY_OUTPUT to avoid conflict in the global setting.<br />
<br />
=== How can I get or set environment variables? ===<br />
<br />
CMake names environment variables using an ENV prefix and surrounding the names in curly braces. Here is an example:<br />
<br />
<pre><br />
MESSAGE("$ENV{PATH}")<br />
</pre><br />
<br />
Reading variables will work in any version of CMake. Writing to them works in CMake 2.2 and higher using the following syntax:<br />
<br />
<pre><br />
SET(ENV{HELLO} "World")<br />
</pre><br />
<br />
Note that there is currently no way to tell apart an empty environment variable value from a variable that is not set at all.<br />
<br />
One should avoid using environment variables for controlling the flow of CMake code (such as in IF commands). The build system generated by CMake may re-run CMake automatically when CMakeLists.txt files change. The environment in which this is executed is controlled by the build system and may not match that in which CMake was originally run. If you want to control build settings on the CMake command line, you need to use cache variables set with the -D option. The settings will be saved in CMakeCache.txt so that they don't have to be repeated every time CMake is run on the same build tree.<br />
<br />
Also, environment variables SET in the CMakeLists.txt ''only'' take effect for cmake itself (''configure-time''), so you cannot use this method to set an environment variable that a custom command might need (''build-time''). Barring environment variable support by various CMake commands (e.g. add_custom_command(), currently not supported yet), an acceptable workaround may be to invoke shell scripts instead which wrap the commands to be executed.<br />
<br />
=== Why do I have unwanted semicolons ; in my compiler flags? ===<br />
CMake has a list data type. A list is stored as a string of semicolon-separated list elements. Whitespace separated arguments to a SET statement are interpreted as list elements. For instance, SET(var a b c d e) will give "var" a value of a;b;c;d;e and this list can be used by other CMake commands. However, if you pass ${var} to a non-CMake external tool, such as a compiler's command line, you are passing a;b;c;d;e which is not what you want. Instead you either need to pass "${var}", so that the list will be converted to a whitespace-separated string, or you need to SET(var "a b c d e") in the 1st place so that you're working with a string, not a list.<br />
<br />
=== How can I get quoting and escapes to work properly? ===<br />
If you want to escape a character in CMake, you use "\", like in C code. For example, if you wanted to have a quote embedded in a string you would do this: "\"". However, each level of CMake that processes your code will need one level of escaping to work. So, if you configure a file that is read by cmake or cpack and you want to do the same thing, you would do "\\\"". You would still need to escape the " for the first cmake that processes the string. However, this time, you would want to also escape a '\' as well. This would leave the next level of processing with "\"". Also, for custom commands that may get passed to a shell, it maybe required to do escaping for that shell.<br />
<br />
=== Isn't the "Expression" in the "ELSE (Expression)" confusing? ===<br />
Traditional CMakeLists.txt files prior to 2.6.0, require the following syntax. In the IF syntax, the ELSE section requires the same (Expression) as the IF section. This sometimes can make the script kind of hard to follow, take the short example below:<br />
<br />
<pre><br />
IF(WIN32)<br />
...do something...<br />
ELSE(WIN32)<br />
...do something else...<br />
ENDIF(WIN32)<br />
</pre><br />
<br />
You might think that the ELSE section, here containing "...do something else...", is for the WIN32 portion of the script. That is not so! It is actually handling the NOT WIN32 section.<br />
<br />
As of CMake 2.6.0 the ELSE() and ENDIF() constructs can be empty. The same is true for closing constructs on ENDMACRO(), ENDFUNCTION(), and ENDFOREACH(). If you require 2.4.x compatibility, CMake 2.4.3 or greater recognizes the CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS option (which is superfluous in 2.6.0)<br />
<br />
<pre><br />
cmake_minimum_required(VERSION 2.4.3)<br />
set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)<br />
<br />
if(WIN32)<br />
...do something...<br />
elseif(APPLE)<br />
...do something else...<br />
else()<br />
...do something else...<br />
endif()<br />
</pre><br />
<br />
=== Which regular expressions are supported by CMake? ===<br />
<br />
(for further details, please refer to the original CMake implementation source at [http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/kwsys/RegularExpression.hxx.in?root=CMake&view=markup Source/kwsys/RegularExpression.hxx.in])<br />
<br />
When using MATCHES or MATCHALL in an IF command, or using any of the STRING(REGEX ...) commands, CMake expects regular expressions, not globs (wild cards). CMake uses the same regular expression engine above all platforms. Here are the meanings of the metacharacters:<br />
<br />
<pre><br />
^ Matches at beginning of a line<br />
$ Matches at end of a line<br />
. Matches any single character<br />
[ ] Matches any character(s) inside the brackets<br />
[^ ] Matches any character(s) not inside the brackets<br />
- Matches any character in range on either side of a dash<br />
| Matches a pattern on either side of the |<br />
* Matches preceding pattern zero or more times<br />
+ Matches preceding pattern one or more times<br />
? Matches preceding pattern zero or once only<br />
() Saves a matched expression and uses it in a later match<br />
</pre><br />
<br />
Example: "[-][L]([^ ;])+" matches all strings beginning with -L and ending with a space or a semicolon, the usual linkdirs under Linux.<br />
<br />
Here is how to catch a part of a string. The variable test is filled with some content, and then we want to catch the "me":<br />
<br />
<pre><br />
SET(test "hello world ! catch: me if you can")<br />
STRING(REGEX REPLACE ".*catch: ([^ ]+).*" "\\1" result "${test}" )<br />
MESSAGE(STATUS "result= ${result}")<br />
</pre><br />
<br />
This is slightly tricky. The part inside the brackets is available in \\1 . CMake will copy the variable test to the variable result, but then it will replace everything that the regular expression matches with \\1. This means the first regular expression has to match the whole string and the part we want to catch has to be put in parens.<br />
<br />
<pre><br />
-- result= me<br />
</pre><br />
<br />
For those of you who know Perl, the equivalent Perl code could be:<br />
<br />
<pre><br />
$test = "hello world ! catch: me if you can";<br />
$result = $test;<br />
$result =~ s/.*catch: ([^ ]+).*/$1/;<br />
print "-- result= $result\n";<br />
</pre><br />
<br />
There are other ways to do this in Perl, but this is how we do it in CMake because \\1 does not become a variable like $1 does in perl, so there is no SET(result ${\\1}) in CMake.<br />
<br />
<br />
Not sure whether CMake regex implementation supports modifiers for case insensitive matching, thus if this is needed it's perhaps best to do matches on a result of string(TOLOWER ...).<br />
<br />
=== How to convert a semicolon separated list to a whitespace separated string? ===<br />
<br />
<pre><br />
set(foo<br />
abc.c<br />
abc.b<br />
abc.a<br />
)<br />
<br />
foreach(arg ${foo})<br />
set(bar "${bar} ${arg}")<br />
endforeach(arg ${foo})<br />
<br />
message("foo: ${foo}")<br />
message("bar: ${bar}")<br />
</pre><br />
<br />
=== How can I build multiple modes without switching ? ===<br />
To build multiple modes (e.g. Debug and Release) in one shot without constantly running cmake -DCMAKE_BUILD_TYPE=Debug and cmake -DCMAKE_BUILD_TYPE=Release in source tree create a directory for builds eg.:<br />
<br />
<pre><br />
Project-directory/<br />
/Build<br />
</pre><br />
<br />
Inside you can place as many target directories for out-of-source build modes as you want, e.g.:<br />
<br />
<pre><br />
Project-directory/<br />
/Build<br />
/Debug<br />
/Release<br />
</pre><br />
<br />
In each of these directories issue a command (assuming that you have CMakeLists.txt directly in Project-directory)<br />
<br />
<pre><br />
cmake -DCMAKE_BUILD_TYPE=type_of_build ../../<br />
</pre><br />
<br />
to create a cmake cache configured for requested build type.<br />
<br />
Now you can make each build just by entering appropriate directory and executing a make command.<br />
<br />
=== How can I specify my own configurations (for generators that allow it) ? ===<br />
<br />
For generators that allow it (like Visual Studio), CMake generates four configurations<br />
by default: Debug, Release, MinSizeRel and RelWithDebInfo. Many people just need Debug<br />
and Release, or need other configurations. To modify this, you need to change the<br />
variable CMAKE_CONFIGURATION_TYPES in the cache:<br />
<br />
<pre><br />
if(CMAKE_CONFIGURATION_TYPES)<br />
set(CMAKE_CONFIGURATION_TYPES Debug Release DebugMX31 ReleaseMX31)<br />
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING<br />
"Reset the configurations to what we need"<br />
FORCE)<br />
endif()<br />
</pre><br />
<br />
Note that the first line checks whether the generator supports multiple configurations.<br />
<br />
If you just want to add your own configurations while keeping the default ones, you can<br />
use list operations:<br />
<br />
<pre><br />
if(CMAKE_CONFIGURATION_TYPES)<br />
list(APPEND CMAKE_CONFIGURATION_TYPES SuperDuper)<br />
list(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)<br />
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING<br />
"Add the configurations that we need"<br />
FORCE)<br />
endif()<br />
</pre><br />
<br />
=== How can I extend the build modes with a custom made one ? ===<br />
The following code snippet (taken from a CMakeLists.txt) adds a Maintainer mode:<br />
<pre><br />
SET( CMAKE_CXX_FLAGS_MAINTAINER "-Wall -Wabi" CACHE STRING<br />
"Flags used by the C++ compiler during maintainer builds."<br />
FORCE )<br />
SET( CMAKE_C_FLAGS_MAINTAINER "-Wall -pedantic" CACHE STRING<br />
"Flags used by the C compiler during maintainer builds."<br />
FORCE )<br />
SET( CMAKE_EXE_LINKER_FLAGS_MAINTAINER<br />
"-Wl,--warn-unresolved-symbols,--warn-once" CACHE STRING<br />
"Flags used for linking binaries during maintainer builds."<br />
FORCE )<br />
SET( CMAKE_SHARED_LINKER_FLAGS_MAINTAINER<br />
"-Wl,--warn-unresolved-symbols,--warn-once" CACHE STRING<br />
"Flags used by the shared libraries linker during maintainer builds."<br />
FORCE )<br />
MARK_AS_ADVANCED(<br />
CMAKE_CXX_FLAGS_MAINTAINER<br />
CMAKE_C_FLAGS_MAINTAINER<br />
CMAKE_EXE_LINKER_FLAGS_MAINTAINER<br />
CMAKE_SHARED_LINKER_FLAGS_MAINTAINER )<br />
# Update the documentation string of CMAKE_BUILD_TYPE for GUIs<br />
SET( CMAKE_BUILD_TYPE "${CMAKE_BUILD_TYPE}" CACHE STRING<br />
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel Maintainer."<br />
FORCE )<br />
</pre><br />
Notes: The flags used in this example are specific to GCC. Change them as needed for your project. Additionally the SET(CMAKE_BUILD_TYPE) command will override<br />
a CMAKE_BUILD_TYPE previously set in the CMakeLists.txt. A simple "SET(CMAKE_BUILD_TYPE)" does silently overwrite, the change is only visible in the GUI if "CACHE" is set when overriding.<br />
<br />
=== Why does <code>foreach</code> skip empty values? ===<br />
<br />
The code in question is of the form<br />
<br />
<pre><br />
set(var "a;b;;c;d") # list 'a', 'b', '', 'c', 'd'<br />
foreach(v ${var})<br />
# v=a, v=b, v=c, v=d, one at a time<br />
endforeach()<br />
</pre><br />
<br />
and the loop variable 'v' never attains the empty-string value ''.<br />
This is because the <code>${var}</code> syntax is an unquoted argument so the CMake language expands the list and removes the empty value.<br />
The foreach command does not even see the empty value.<br />
One can verify this because the code<br />
<br />
<pre><br />
foreach(v a b "" c d)<br />
...<br />
endforeach()<br />
</pre><br />
<br />
will see the empty value.<br />
<br />
=== Does CMake support precompiled headers? ===<br />
<br />
Yes and no. Every platform does precompiled headers a bit differently, and there is currently no first-class interface provided by CMake and implemented on every platform.<br />
However, CMake does provide enough primitives for projects to use precompiled headers on specific platforms.<br />
Our issue tracker has a [https://gitlab.kitware.com/cmake/cmake/issues/1260 feature request] with attachements providing user-contributed helper macros for some platforms.<br />
<br />
== Writing FindXXX.cmake files ==<br />
<br />
=== What are the rules to write a FindXXX.cmake file? ===<br />
<br />
Let's follow the instructions and the advices in the <br />
Modules/readme.txt [http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup]<br />
file located in the CVS repository.<br />
<br />
=== Why does find_library look in system directories before its PATHS option? ===<br />
<br />
The code in question is often of the form<br />
<br />
<pre><br />
find_library(FOO_LIBRARY NAMES foo PATHS /opt/foo/lib)<br />
</pre><br />
<br />
CMake will find "<code>/usr/lib/libfoo.so</code>" instead of "<code>/opt/foo/lib/libfoo.so</code>" if both exist.<br />
The reason is that /opt/foo/lib is a <i>hard-coded guess</i> of the location.<br />
The documentation of <code>[http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_library find_library]</code> specifies the search order.<br />
User, project, and system configuration variables are always more local than hard-coded guesses and should override them, so<br />
the PATHS option is used last.<br />
<br />
Some find-modules compute probable locations based on other information <i>available from the system</i> such as a project-specific environment variable.<br />
The HINTS option (CMake 2.6 and higher) takes precedence over system directories specifically for this case:<br />
<br />
<pre><br />
file(TO_CMAKE_PATH "$ENV{FOO_LIB_DIR}" FOO_LIB_DIR)<br />
find_library(FOO_LIBRARY NAMES foo HINTS ${FOO_LIB_DIR})<br />
</pre><br />
<br />
CMake will find "<code>$ENV{FOO_LIB_DIR}/libfoo.so</code>" before "<code>/usr/lib/libfoo.so</code>".<br />
<br />
== Finding and using external packages ==<br />
<br />
=== How do I use CMake to generate SWIG wrapper libraries? ===<br />
<br />
CMake version 2 includes a module that supports the generation of SWIG wrapper libraries. The SWIG package defines the following macros: SWIG_ADD_MODULE and SWIG_LINK_LIBRARIES.<br />
<br />
<pre><br />
# This example shows how to use python<br />
# Currently these languages have been tested:<br />
# perl tcl ruby php4 pike<br />
<br />
FIND_PACKAGE(SWIG REQUIRED)<br />
INCLUDE(${SWIG_USE_FILE})<br />
<br />
FIND_PACKAGE(PythonLibs)<br />
INCLUDE_DIRECTORIES(${PYTHON_INCLUDE_PATH})<br />
<br />
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})<br />
<br />
SET(CMAKE_SWIG_FLAGS "")<br />
<br />
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES CPLUSPLUS ON)<br />
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES SWIG_FLAGS "-includeall")<br />
SWIG_ADD_MODULE(example python<br />
example.i example.cxx)<br />
SWIG_LINK_LIBRARIES(example ${PYTHON_LIBRARIES})<br />
<br />
</pre><br />
<br />
<pre><br />
# This example shows how to use tcl<br />
PROJECT(TCL_WRAP)<br />
SET ( MODULE_NAME project )<br />
SET ( INTERFACE_FILES project.i)<br />
SET ( SRC_FILES Vertex.h Vertex.cxx Shapes.h Shapes.cxx )<br />
<br />
FIND_PACKAGE(SWIG REQUIRED)<br />
INCLUDE(${SWIG_USE_FILE})<br />
<br />
# Look for TCL<br />
INCLUDE_DIRECTORIES(${TCL_INCLUDE_PATH})<br />
<br />
FIND_LIBRARY(TCL_LIBRARY NAMES tcl tcl84 tcl83 tcl82 tcl80<br />
PATHS /usr/lib /usr/local/lib)<br />
IF (TCL_LIBRARY)<br />
TARGET_ADD_LIBRARY (${MODULE_NAME} TCL_LIBRARY)<br />
ENDIF (TCL_LIBRARY)<br />
<br />
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})<br />
<br />
SET(CMAKE_SWIG_FLAGS "-c++")<br />
<br />
SET_SOURCE_FILES_PROPERTIES(${INTERFACE_FILES} PROPERTIES CPLUSPLUS ON)<br />
SET_SOURCE_FILES_PROPERTIES(${INTERFACE_FILES} PROPERTIES CMAKE_SWIG_FLAGS "-includeall")<br />
SWIG_ADD_MODULE(${MODULE_NAME} tcl ${INTERFACE_FILES} ${SRC_FILES})<br />
SWIG_LINK_LIBRARIES(${MODULE_NAME} ${TCL_LIBRARIES})<br />
</pre><br />
<br />
If you get errors indicating that C and C++ include files cannot be found, like,<br />
<pre><br />
Error: Unable to find 'string.h'<br />
Error: Unable to find 'time.h'<br />
Error: Unable to find 'string'<br />
Error: Unable to find 'functional'<br />
Error: Unable to find 'utility'<br />
Error: Unable to find 'limits.h'<br />
Error: Unable to find 'fstream'<br />
Error: Unable to find 'sys/times.h'<br />
Error: Unable to find 'unistd.h'<br />
Error: Unable to find 'malloc.h'<br />
...<br />
</pre><br />
try setting the <code>-includeall</code> property on fewer source files:<br />
<pre><br />
# Try doing this on fewer files<br />
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES SWIG_FLAGS "-includeall")<br />
</pre><br />
In particular, you may need <code>-includeall</code> only on the top-level <code>.i</code> files.<br />
<br />
=== How do I use CMake to build LaTeX documents? ===<br />
Use the following approach. Note that you have to set LATEX_COMPILE to LaTeX executable, DVIPDF_COMPILE to dvi to pdf converter. Also, the LaTeX source is TDocument.tex and the result is called TDocument.pdf. Note that this uses commands in CMake version 1.8 or later.<br />
<br />
<pre><br />
PROJECT(Document)<br />
IF(LATEX_COMPILE)<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi<br />
DEPENDS ${Document_BINARY_DIR}/TDocument.tex<br />
COMMAND ${LATEX_COMPILE} <br />
ARGS ${Document_SOURCE_DIR}/TDocument.tex <br />
)<br />
ENDIF(LATEX_COMPILE)<br />
<br />
IF(DVIPDF_COMPILE)<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf<br />
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi <br />
COMMAND ${DVIPDF_COMPILE}<br />
ARGS ${Document_SOURCE_DIR}/TDocument.dvi<br />
)<br />
ENDIF(DVIPDF_COMPILE)<br />
</pre><br />
<br />
<pre><br />
ADD_CUSTOM_TARGET(LaTeXDocument ALL echo<br />
DEPENDS ${Document_BINARY_DIR}/TDocument.pdf<br />
)<br />
</pre><br />
<br />
The following uses commands in CMake version 2.0 and later<br />
<br />
<pre><br />
PROJECT(Document)<br />
# <br />
# Find LaTeX<br />
#<br />
FIND_PACKAGE(LATEX)<br />
</pre><br />
<br />
<pre><br />
IF(LATEX_COMPILER)<br />
ADD_CUSTOM_COMMAND( <br />
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi<br />
COMMAND ${LATEX_COMPILER}<br />
ARGS ${Document_SOURCE_DIR}/TDocument.tex<br />
DEPENDS ${Document_SOURCE_DIR}/TDocument.tex<br />
COMMENT "Tex2dvi"<br />
)<br />
</pre><br />
<br />
<pre><br />
IF(DVIPS_CONVERTER)<br />
ADD_CUSTOM_COMMAND( <br />
OUTPUT ${Document_BINARY_DIR}/TDocument.ps<br />
COMMAND ${DVIPS_CONVERTER}<br />
ARGS ${Document_BINARY_DIR}/TDocument.dvi<br />
-o ${Document_BINARY_DIR}/TDocument.ps<br />
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi<br />
COMMENT "dvi2ps"<br />
)<br />
<br />
IF(PS2PDF_CONVERTER)<br />
ADD_CUSTOM_COMMAND( <br />
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf<br />
COMMAND ${PS2PDF_CONVERTER}<br />
ARGS ${Document_BINARY_DIR}/TDocument.ps<br />
DEPENDS ${Document_BINARY_DIR}/TDocument.ps<br />
COMMENT "ps2pdf"<br />
)<br />
</pre><br />
<br />
<pre><br />
ADD_CUSTOM_TARGET(LaTeXDocument ALL echo<br />
DEPENDS ${Document_BINARY_DIR}/TDocument.pdf<br />
)<br />
ENDIF(PS2PDF_CONVERTER)<br />
ENDIF(DVIPS_CONVERTER)<br />
ENDIF(LATEX_COMPILER)<br />
</pre><br />
<br />
=== How do I get LaTeX references to be correct? ===<br />
When your latex document contains references (e.g. \ref{...} command) you get to run two passes of latex. In the<br />
most general case, i.e. when additionally your document uses a bibtex bibliography, you shall need three<br />
passes of latex (and one pass of bibtex):<br />
# latex (first pass: for bibtex to have an .aux file)<br />
# bibtex (for generating the .bbl file)<br />
# latex (second pass)<br />
# latex (third pass)<br />
<br />
The following code snippet illustrates how you can "pervert" the bibtex and latex generated<br />
auxilary files (.aux, .log, .dvi, .bbl...) to create an "artificial" set of CMake dependencies.<br />
The side-effect of those dependencies should hopefully be the above described sequence of calls<br />
to latex and bibtex<br />
<pre><br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.aux<br />
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/UsersManual.tex<br />
COMMAND ${LATEX_COMPILER}<br />
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual<br />
COMMENT "Latex (first pass)"<br />
)<br />
<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl<br />
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.aux<br />
COMMAND ${BIBTEX_COMPILER}<br />
ARGS -terse ${CMAKE_CURRENT_BINARY_DIR}/UsersManual<br />
COMMENT "Bibtex"<br />
)<br />
<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.dvi<br />
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl<br />
COMMAND ${LATEX_COMPILER}<br />
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual<br />
COMMENT "Latex (second pass)"<br />
)<br />
<br />
ADD_CUSTOM_COMMAND(<br />
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.log<br />
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl<br />
${CMAKE_CURRENT_BINARY_DIR}/UsersManual.dvi<br />
COMMAND ${LATEX_COMPILER}<br />
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual<br />
COMMENT "Latex (third pass)"<br />
)<br />
# Eventually trigger the whole process<br />
ADD_CUSTOM_TARGET(LaTeXDocument ALL echo<br />
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.log<br />
)<br />
</pre><br />
<br />
=== How can I set TEXINPUTS for a LaTeX compilation? ===<br />
First note that most often you can avoid using TEXINPUTS by copying all the necessary files (.tex source file and<br />
included graphic files e.g. .eps files) from your PROJECT_SOURCE_DIR hirarchy to your PROJECT_BINARY_DIR subdir<br />
[refer to CONFIGURE_FILE with the COPYONLY flag set for copying files]. Since by default latex uses the current working directory as value for TEXINPUTS you should be all set. As expected, this trick is quick AND dirty since your<br />
concerned PROJECT_BINARY_DIR subdir now contains files that are NOT generated by CMake (in the sense that those<br />
files are not the result of a system command but were merely duplicated)... <br />
<br />
If you consider it is cleaner or easier to define a TEXINPUTS environment variable [the latex command probably<br />
misses a -I flag] you can find an example in the InsightDocuments cvs archive (refer to the section "cvs access"<br />
near the bottom of Kitware's ITK download page) or use google with keywords "ITK_TEXINPUTS CONFIGURE_FILE".<br />
Look at InsightDocuments/CourseWare/Training/Vis2003/Latex/CMakeLists.txt and search for e.g. "LaTeXWrapper.sh.in".<br />
<br />
Roughly the mechanism goes:<br />
* SET ITK_TEXINPUTS with the desired TEXINPUTS<br />
* CONFIGURE_FILE "InsightDocuments/CourseWare/Training/Vis2003/LaTeXWrapper.sh.in" which generates an sh shell script setting the shell variable TEXINPUTS prior to running the latex command<br />
* use ADD_CUSTOM_COMMAND to invoke this shell script<br />
This very example is Win32 portable (except that LaTeXWrapper.bat.in generates a .bat shell script)<br />
<br />
== Library questions ==<br />
<br />
=== Can I build both shared and static libraries with one ADD_LIBRARY command? ===<br />
<br />
No. Each library you build must have a unique target name, i.e. the "libname" field of the ADD_LIBRARY command. That way, CMake can track dependencies separately for each library. Libraries can have the same OUTPUT_NAME, see the SET_TARGET_PROPERTIES command, but this is not the default.<br />
<br />
=== Does that mean I have to build all my library objects twice, once for shared and once for static?! I don't like that! ===<br />
<br />
In practice, most libraries have different defines and compiler flags for the shared vs. static cases. So you would have to build all your library objects twice anyways. However, if you happen to have '''''exactly''''' the same defines and compiler flags for the shared vs. static cases...<br />
<br />
...if you're using Linux and a GCC-style linker, you could do the following. Note that for this to work correctly on linux, the zzSTATIC source files should have been compiled with "-fPIC" to ensure they will work in a shared library.<br />
<br />
<pre><br />
IF(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC)<br />
ADD_LIBRARY(zzSTATIC STATIC -fPIC)<br />
ADD_LIBRARY(zzDYNAMIC SHARED)<br />
TARGET_LINK_LIBRARIES(zzDYNAMIC -Wl,-whole-archive zzSTATIC -Wl,-no-whole-archive)<br />
ENDIF(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC)<br />
</pre><br />
<br />
...if you want a cross-platform approach that works on all compilers, not just GCC or Linux, you could extract the locations of previously built object files and insert them directly into the libraries that need them. This is documented in [http://www.cmake.org/Bug/view.php?id=5155 CMake Feature Request #5155: standard way to locate object files]. Unfortunately this approach relies on CMake's internal implementation, and that implementation could change in the future, breaking your code.<br />
<br />
=== How do I make my shared and static libraries have the same root name, but different suffixes? ===<br />
Set the OUTPUT_NAME of your shared and static libraries to the same thing.<br />
<br />
<pre><br />
ADD_LIBRARY(foo SHARED ${foo_sources})<br />
ADD_LIBRARY(foo-static STATIC ${foo_sources})<br />
# The library target "foo" already has a default OUTPUT_NAME of "foo", so we don't need to change it.<br />
# The library target "foo-static" has a default OUTPUT_NAME of "foo-static", so change it.<br />
SET_TARGET_PROPERTIES(foo-static PROPERTIES OUTPUT_NAME "foo")<br />
# Now the library target "foo-static" will be named "foo.lib" with MS tools.<br />
# This conflicts with the "foo.lib" import library corresponding to "foo.dll",<br />
# so we add a "lib" prefix (which is default on other platforms anyway):<br />
SET_TARGET_PROPERTIES(foo-static PROPERTIES PREFIX "lib")<br />
</pre><br />
<br />
One more detail is needed with CMake 2.6.x and lower (but not CMake 2.8 or higher). If you are building your shared and static libraries in the same directory, you will also need the following to keep your shared and static libraries from clobbering each other during the build.<br />
<br />
<pre><br />
# Help CMake 2.6.x and lower (not necessary for 2.8 and above, but doesn't hurt):<br />
SET_TARGET_PROPERTIES(foo PROPERTIES CLEAN_DIRECT_OUTPUT 1)<br />
SET_TARGET_PROPERTIES(foo-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)<br />
</pre><br />
<br />
=== How do I rename a library after it has already been built? ===<br />
You don't rename it. It's been built! Its name is whatever CMakeLists.txt says it's supposed to be.<br />
<br />
Perhaps you want to copy the library to a different name. But, are you sure that's what you want to do? You could just change the name in your ADD_LIBRARY command or change its OUTPUT_NAME property using SET_TARGET_PROPERTY(). If you really really want to copy the library to a different name, try:<br />
<br />
<pre><br />
GET_TARGET_PROPERTY(LIB_NAME Foo LOCATION)<br />
GET_TARGET_PROPERTY(Bar_prefix Foo PREFIX)<br />
GET_TARGET_PROPERTY(Bar_suffix Foo SUFFIX)<br />
SET(NEW_LIB_NAME ${Bar_prefix}Bar${Bar_suffix})<br />
<br />
ADD_CUSTOM_COMMAND(<br />
TARGET Foo<br />
POST_BUILD<br />
COMMAND ${CMAKE_COMMAND} -E copy ${LIB_NAME} ${NEW_LIB_NAME}<br />
)<br />
</pre><br />
<br />
On Windows you may also want to copy the .dll import lib, using the same approach as above, but with IMPORT_PREFIX and IMPORT_SUFFIX. ''Problem: LOCATION only refers to 1 file, the .dll. What is a simple way to get the location of the import lib? Could provide a complicated way, but that's annoying.''<br />
<br />
=== Does CMake support "convenience" libraries? ===<br />
No. CMake does not currently support convenience libraries. A "convenience" library, as GNU libtool calls it, is an archive of objects to be mixed into other libraries. Other libraries "link" to the convenience library, but the convenience library does not export any symbols; GNU libtool never installs the convenience library; no programs ever link to the convenience library.<br />
<br />
This does '''not''' mean that a project using convenience libraries cannot be converted to CMake. Instead the source files may be listed in each target that needs them. They will be built for each target separately using all the preprocessor definitions and flags configured for that target.<br />
<br />
=== Why are libraries linked to my shared library included when something links to it? ===<br />
This question arises when one has a library B which links to some library A. When a third target, say C, links to B, CMake will automatically include C to A also. When the libraries are static, then this is always necessary. When the libraries are shared, this is the default behavior provided by CMake with the simple <code>target_link_libraries signature</code>. CMake 3.0 and above provide <code>PUBLIC</code>, <code>PRIVATE</code>, and <code>INTERFACE</code> options to target_link_libraries to specify whether linking should be used for just the implementation and/or made part of the interface (transitive dependencies):<br />
<br />
<pre><br />
target_link_libraries(myLibrary PRIVATE myImplDependency)<br />
</pre><br />
<br />
CMake 2.8.7 and above provide <code>LINK_PUBLIC</code> and <code>LINK_PRIVATE</code> options for the same purpose (these were superseded by PUBLIC/PRIVATE/INTERFACE in 3.0 for consistency with options other commands like <code>target_compile_definitions</code>).<br />
<br />
=== CMake dependency scanner ===<br />
<br />
CMake does not preprocess source files while scanning dependencies. Code like<br />
<pre><br />
#if 0<br />
# include "bla.h"<br />
#endif<br />
</pre><br />
will result in a dependency on "bla.h". This sometimes leads to source files recompiling unnecessarily but will not break the build.<br />
<br />
== Installation questions ==<br />
<br />
=== Does CMake's "make install" support DESTDIR? ===<br />
'''Yes''', especially when the build-system generator uses CMake's builtin support for installing files: Simply define the DESTDIR environment variable during installation and CMake will treat that value as the root of the file system for all installation paths; naturally, the DESTDIR path must be absolute.<br />
<br />
For example, if the Makefile generator is used, then all of the following are example usages of DESTDIR (perhaps assuming the bash shell for the last 2):<br />
<br />
<pre><br />
(1) make install DESTDIR="/some/absolute/path"<br />
(2) make DESTDIR="/some/absolute/path" install<br />
(3) DESTDIR="/some/absolute/path" make install<br />
(4) export DESTDIR="/some/absolute/path<br />
make install<br />
</pre><br />
<br />
=== Can I do "make uninstall" with CMake?===<br />
By default, CMake does not provide the "make uninstall" target, so you cannot do this. We do not want "make uninstall" to remove useful files from the system.<br />
<br />
If you want an "uninstall" target in your project, then nobody prevents you from providing one. You need to delete the files listed in install_manifest.txt file. Here is how to do it. First create file cmake_uninstall.cmake.in in the top-level directory of the project:<br />
<br />
<pre>if(NOT EXISTS "@CMAKE_BINARY_DIR@/install_manifest.txt")<br />
message(FATAL_ERROR "Cannot find install manifest: @CMAKE_BINARY_DIR@/install_manifest.txt")<br />
endif(NOT EXISTS "@CMAKE_BINARY_DIR@/install_manifest.txt")<br />
<br />
file(READ "@CMAKE_BINARY_DIR@/install_manifest.txt" files)<br />
string(REGEX REPLACE "\n" ";" files "${files}")<br />
foreach(file ${files})<br />
message(STATUS "Uninstalling $ENV{DESTDIR}${file}")<br />
if(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")<br />
exec_program(<br />
"@CMAKE_COMMAND@" ARGS "-E remove \"$ENV{DESTDIR}${file}\""<br />
OUTPUT_VARIABLE rm_out<br />
RETURN_VALUE rm_retval<br />
)<br />
if(NOT "${rm_retval}" STREQUAL 0)<br />
message(FATAL_ERROR "Problem when removing $ENV{DESTDIR}${file}")<br />
endif(NOT "${rm_retval}" STREQUAL 0)<br />
else(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")<br />
message(STATUS "File $ENV{DESTDIR}${file} does not exist.")<br />
endif(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")<br />
endforeach(file)<br />
</pre><br />
<br />
Then in the top-level CMakeLists.txt add the following logic:<br />
<br />
<pre># uninstall target<br />
if(NOT TARGET uninstall)<br />
configure_file(<br />
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"<br />
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"<br />
IMMEDIATE @ONLY)<br />
<br />
add_custom_target(uninstall<br />
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)<br />
endif()<br />
</pre><br />
<br />
Now you will have an "uninstall" target at the top-level directory of your build tree.<br />
<br />
Instead of creating an "uninstall" target, Unix users could enter this command in the shell:<br />
<br />
<pre><br />
xargs rm < install_manifest.txt<br />
</pre><br />
<br />
== Distribution questions ==<br />
<br />
=== Where is "make dist"? ===<br />
<br />
CMake doesn't create a "make dist" target.<br />
<br />
=== What is the best way to distribute source code or binaries for a cmake-based project? ===<br />
<br />
For creating source or binary packages there is now [[CMake#CPack | CPack]] coming with CMake, see the <br />
[[ CMake#CPack | documentation]].<br />
<br />
Of course you can also use any other ways to create packages.<br />
<br />
== Platform-specific questions ==<br />
=== How do I build universal binaries on Mac OS X? ===<br />
Before running CMake with an empty build tree, set the CMAKE_OSX_ARCHITECTURES environment variable. It should be set to contain a ; separated list of architectures that you want in the binary. For example, for 32-bit PowerPC and Intel you would do this:<br />
<br />
CMAKE_OSX_ARCHITECTURES=ppc;i386<br />
<br />
If you wish to build both as 32 and 64 bit, do this:<br />
<br />
CMAKE_OSX_ARCHITECTURES=ppc;i386;ppc64;x86_64<br />
<br />
You can also set the same named CMake cache variable on an existing binary tree. This works with both makefiles and the Xcode generator. <br />
<br />
In addition, you can also set the CMAKE_OSX_SYSROOT variable to point to the sysroot (aka Mac OS SDK) to be used. CMake will attempt to pick one on your system, but it can be changed in the cache or via an environment variable before running CMake. The 10.4u SDK or later must be used to create a Universal Binary.<br />
<br />
Universal Binaries are essentially cross compilation and so you should avoid using TRY_RUN, especially for things like testing endianess or variable size because the result will only be correct for one architecture.<br />
<br />
Lastly, note that CTest is only able to test one architecture. See bug 6157.<br />
<br />
=== How can I apply resources on Mac OS X automatically? ===<br />
Using ADD_CUSTOM_COMMAND. For example, let's say you are creating executable MyExecutable, which needs the resources file Carbon.r. All you do is add a custom rule which is executed after the executable is linked:<br />
<br />
<pre><br />
ADD_EXECUTABLE(MyExecutable ${MyExecutable_SRCS})<br />
GET_TARGET_PROPERTY(MyExecutable_PATH MyExecutable LOCATION)<br />
<br />
IF(APPLE)<br />
FIND_PROGRAM(APPLE_RESOURCE Rez /Developer/Tools)<br />
IF(APPLE_RESOURCE)<br />
ADD_CUSTOM_COMMAND(TARGET MyExecutable POST_BUILD<br />
COMMAND ${APPLE_RESOURCE} Carbon.r -o ${MyExecutable_PATH})<br />
ENDIF(APPLE_RESOURCE)<br />
ENDIF(APPLE)<br />
</pre><br />
<br />
This will execute:<br />
<br />
<pre><br />
/Developer/Tools/Rez Carbon.r -o /binary/path/MyExecutable<br />
</pre><br />
<br />
after MyExecutable is linked.<br />
<br />
'Rez' may be located elsewhere on disk, depending on the version of Mac OS X and Xcode. You can use 'which Rez' in Terminal to find it's full path.<br />
<br />
=== Why does FIND_LIBRARY not find .DLL libraries under WIN32? ===<br />
For those who come from a Unix background to MS Windows:<br />
<br />
You never link directly to the .dll, you have to link against the import library .lib for the .dll.<br />
<br />
Linking against dynamic libraries (.dll under Windows) is quite different from linking against ELF shared objects (.so) under platforms like Linux or NetBSD. In Windows, there are two types of library, a static library and an import library (both confusingly use the .lib extension, however). In Windows, when you build an import library (A.lib) you will get a corresponding (A.dll) that you only need at runtime. At compile time you will need the import library.<br />
<br />
Conclusion: There is no need to find a .dll for linking. You only need to find the .lib import library.<br />
<br />
Some more details can be found here: [http://xenophilia.org/winvunix.html].<br />
<br />
=== Why am I getting a linker error to _mainCRTStartup under WIN32? ===<br />
Your program is a GUI application using WinMain (/subsystem:windows) and not a console application using main. You have to use the WIN32 option with the ADD_EXECUTABLE command.<br />
<br />
<pre><br />
ADD_EXECUTABLE(exename WIN32 source1 source2 ... sourceN)<br />
</pre><br />
<br />
The second argument to ADD_EXECUTABLE can be WIN32. This indicates that the executable, when compiled on Windows, is a Windows app (using WinMain) and not a console app (using main). Please note that on Unix platforms, CMake ignores the WIN32 and the compiler will use "main" in any case.<br />
<br />
=== Why do I get this error: nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv ===<br />
<br />
This is because the application is using both the static and dll versions of the MFC library.<br />
To fix the problem, you can do the following:<br />
<br />
<pre><br />
SET(CMAKE_MFC_FLAG 2) # force the IDE to use static MFC<br />
ADD_DEFINITIONS(-D_AFXDLL) # make sure if afx.h is included the dll MFC is used<br />
</pre><br />
<br />
=== How to use MFC with CMake ===<br />
To use MFC, the CMAKE_MFC_FLAG variable must be set as follows:<br />
<br />
<pre><br />
0: Use Standard Windows Libraries<br />
1: Use MFC in a Static Library<br />
2: Use MFC in a Shared DLL <br />
</pre><br />
<br />
This can be set in a CMakeLists.txt file and will enable MFC in the application. It should be set to 1 or 2. This is used in visual studio 6 and 7 project files. The CMakeSetup dialog uses MFC and the CMakeLists.txt looks like this:<br />
<br />
<pre><br />
ADD_DEFINITIONS(-D_AFXDLL)<br />
SET(CMAKE_MFC_FLAG 2) <br />
ADD_EXECUTABLE(CMakeSetup WIN32 ${SRCS})<br />
</pre><br />
<br />
Note that visual studio 9 project files do not appear to work with CMAKE_MFC_FLAG 1; this may be related to [http://www.cmake.org/Bug/view.php?id=7056 bug 7056].<br />
<br />
In order to use MFC with UNICODE, you must also [http://msdn.microsoft.com/en-us/library/dybsewaf.aspx specify the entry point wWinMainCRTStartup]. For example:<br />
<br />
<pre><br />
set(CMAKE_MFC_FLAG 2)<br />
set_target_properties(MyApp PROPERTIES<br />
COMPILE_DEFINITIONS _AFXDLL,_UNICODE,UNICODE,_BIND_TO_CURRENT_CRT_VERSION,_BIND_TO_CURRENT_MFC_VERSION<br />
LINK_FLAGS "/ENTRY:\"wWinMainCRTStartup\"")<br />
</pre><br />
<br />
See [http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions this article] as to why _BIND_TO_CURRENT_CRT_VERSION and _BIND_TO_CURRENT_MFC_VERSION are necessary for Visual Studio 2008 SP1.<br />
<br />
=== How To Put Files in Folders in Visual Studio Projects ===<br />
The Visual Studio IDE supports putting files into folders.<br />
CMake can be used to put files in folders with the SOURCE_GROUP <br />
command. <br />
<br />
<pre><br />
SOURCE_GROUP(name [REGULAR_EXPRESSION regex] [FILES src1 src2 ...])<br />
</pre><br />
<br />
Defines a group into which sources will be placed in project files. This is mainly used to setup file tabs in Visual Studio. Any file whose name is listed or matches the regular expression will be placed in this group provided the source file is being passed to ADD_EXECUTABLE or ADD_LIBRARY.<br />
<br />
<pre><br />
For example:<br />
SOURCE_GROUP(FooFiles FILES foo.cxx)<br />
SOURCE_GROUP(BarFiles FILES bar.cxx)<br />
ADD_LIBRARY(foo foo.cxx bar.cxx)<br />
</pre><br />
<br />
In the event a file matches multiple groups, the LAST group that explicitly lists the file will be favored, if any. If no group explicitly lists the file, the LAST group whose regular expression matches the file will be favored. For backwards compatibility this command is also supports the format SOURCE_GROUP(name regex).<br />
<br />
As a convenience to developers CMake automatically adds standard header files to a "Header Files" folder and standard source files to a "Source Files" folder for Visual Studio Projects. This can be overridden via the SOURCE_GROUP method documented above.<br />
<br />
=== How to create Visual Studio 6 Projects that contain only a single build type===<br />
For Visual Studio.NET (version 7.0 and above) it is possible to set the CMAKE_CONFIGURATION_TYPES variable to the build type(s) (Debug/Release/...) that you want. This does not work for Visual Studio 6. There is however a way to achieve this. To create your own set of configurations:<br />
<br />
# Create a directory in which you copy the files *.dsptemplate and CMakeVisualStudio6Configurations.cmake from CMake's Templates directory.<br />
# Edit the .cmake file and change the SET(CMAKE_CONFIGURATION_TYPES ...) line to set the build types that you want in your set.<br />
# Edit the *Header.dsptemplate files to contain only the configuration types you want in your set.<br />
# In your CMakeLists.txt file, set the MSPROJECT_TEMPLATE_DIRECTORY to the directory that you created.<br />
<br />
<br />
That's it. Run CMake and your new configuration files will be created.<br />
<br />
Note: Editing the *Header.dsptemplates files should be done very carefully. Here are some guidelines:<br />
<br />
- You MUST remove the targets that you do not want in your set at the bottom of the file (e.g. '# Name "OUTPUT_LIBNAME - Win32 MinSizeRel"')<br />
- You can remove the '!IF "$(CFG)" == ...' until '!ELSEIF "$(CFG)" == ...' or '!ELSEIF "$(CFG)" == ...' until '!ENDIF' lines for the configurations you do not want. Make sure that the resulting code still starts with '!IF ...' and ends with '!ENDIF' with any number of '!ELSEIF' sections in between. If you create templates for a single configuration (aka makefile), it is possible to remove everything starting from '!IF' until and including '!ENDIF' and leave only the contents of the relevant section intact.<br />
- Do not edit the lines starting with '!MESSAGE' as the changes may - and probably will - corrupt your resulting DSP files. The only thing I was able to change without corrupting the DSP is to remove the irrevant configurations from the "Possible choices for configuration are:" list.<br />
<br />
If you have only a single configuration in your set, you may want to get rid of the intermediate dir that MsDev creates. You can do that by setting:<br />
# PROP BASE Output_Dir ""<br />
# PROP BASE Intermediate_Dir ""<br />
# PROP Intermediate_Dir ""<br />
# PROP Output_Dir "LIBRARY_OUTPUT_PATH"<br />
or<br />
# PROP Output_Dir "EXECUTABLE_OUTPUT_PATH"<br />
<br />
Additionally you should then also edit the '# ADD LINK32' line in the DLLHeader.dsptemplate file. Change for example '/out:"LIBRARY_OUTPUT_PATHDebug/OUTPUT_LIBNAMEDEBUG_POSTFIX.dll"' into '/out:"LIBRARY_OUTPUT_PATHOUTPUT_LIBNAMEDEBUG_POSTFIX.dll"' (Note that the configuration name and also the slash are removed).<br />
<br />
It is even possible to rename the pre-defined configurations of CMake in this way. Let's say you prefer 'PreProduction' over 'RelWithDebInfo'. You can change the name in the *.dsptemplate files, but you should also change it in the CMakeVisualStudio6Configurations.cmake file. Be careful, however. Only entries relevant to the configuration name should be changed. Do not change the /debug options and the entries that contain the build type in capital characters. Internally in CMake the build type will still remain 'RelWithDebInfo', so also the CMAKE_BUILD_TYPE should be set to the old value. You can only change the way it is named in MSDev.<br />
<br />
Note: Apparently MsDev as command-line build tool only performs a partial check on the build type. It will match all configuration types that CONTAIN the build type in their name. (e.g. if you have renamed RelWithDebInfo to DebugRelease, Debug will build Debug and DebugRelease, Release will build Release and DebugRelease. This may be exactly what you want, but be warned.)<br />
<br />
=== Can CMake set the Debugging/Working Directory property in Visual Studio projects? ===<br />
<br />
Not directly. The value of this property is not stored in the project files. It is stored in extra files created by the IDE when a solution is loaded (VS .NET 2003 uses a hidden .suo file next to the .sln solution file). The format of these files is not known to CMake and cannot be generated. In some versions of VS the files are binary and not human readable.<br />
<br />
However, for Visual Studio versions at least 2005 and newer, [[User:Rpavlik|Ryan Pavlik]] maintains CMake modules that can create these files: [https://github.com/rpavlik/cmake-modules/blob/master/CreateLaunchers.cmake main script], also requires [https://github.com/rpavlik/cmake-modules/tree/master/launcher-templates this directory].<br />
<br />
=== Why does CMakeSetup with the message "LINK : fatal error LNK1104: cannot open file 'user32.lib'" while configuring a project? ===<br />
<br />
The path to the SDK libs (user32.lib) must be added by the IDE when the<br />
project generator "Visual Studio 8 2005" is used, because cmake uses<br />
VCExpress.exe and on the fly generated project files to check<br />
for compiling (VCExpress.exe reads some config files for the<br />
compiler/linker options)<br />
<br />
So add the sdk lib path (...\Microsoft Platform SDK\Lib) at Tools->Options->Projects and Solutions->VC++ Directories->Library files<br />
<br />
See also:<br />
*http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/<br />
<br />
=== How can I avoid the error "Arg list too long" when running make? ===<br />
This error is sometimes encountered when building a static library with many object files using Unix make command. It typically looks something like this:<br />
<br />
<pre><br />
gmake[2]: execvp: /bin/sh: Arg list too long<br />
</pre><br />
<br />
When make tries to run the archiver program to build the static library the shell it uses complains that the argument list is too long. In some shells this can be fixed by setting an environment variable such as <tt>ARG_MAX</tt> to extend the length of the command line it will allow.<br />
<br />
The error can also happen when linking shared libraries, and can be solved by upping the sysconf parameter MAX_ARG. <br />
<br />
On AIX this can be done with the command:<br />
<br />
<pre><br />
chdev -l sys0 -a ncargs='30'<br />
</pre><br />
<br />
Obviously an alternative approach might be to contemplate reducing the object count by splitting off some suitable group of objects into their separate static library.<br />
<br />
=== How can I find out platforms definitions, search paths, etc. from gcc ?===<br />
<br />
The following is really the best if not only way to get information about predefined macros with a GNU compiler:<br />
<pre><br />
$ touch empty.c<br />
$ gcc -v -dD -E empty.c <br />
</pre><br />
This will give you all you might want to know about the preprocessor, the builtin include search dirs and all<br />
predefined definitions, so you can check whether it's __LINUX or _LINUX_ or _APPLE_ or __APPLE etc. <br />
The empty file and all these parameters are really required. You probably want to redirect the output (both stdout and stderr) to a file.<br />
If you want the information for C++, use a C++ file suffix for the empty file.<br />
<br />
This is how you can get the builtin library search paths:<br />
<pre><br />
$ gcc --print-search-dirs<br />
</pre><br />
<br />
=== How can I get a windows registry key ?===<br />
<br />
The only thing to know is that you can't use just the "SET" command in place of "GET" command.<br />
CMake read the value from the registry only when you "get" it from the cache. For instance :<br />
<br />
<pre><br />
GET_FILENAME_COMPONENT(SDK_ROOT_PATH "[HKEY_LOCAL_MACHINE\\SOFTWARE\\PACKAGE;Install_Dir]" ABSOLUTE CACHE)<br />
</pre><br />
<br />
If a key name (ex: Install_Dir in this case) was not specified , the Default key value will be get.<br />
Now you could use the SDK_ROOT_PATH to add include and lib path to your project :<br />
<br />
<pre><br />
INCLUDE_DIRECTORIES(<br />
${SDK_ROOT_PATH}/include<br />
)<br />
<br />
LINK_DIRECTORIES(<br />
${SDK_ROOT_PATH}/lib<br />
)<br />
</pre><br />
<br />
You can also read a registry key in the PATHS section of a FIND_LIBRARY, FIND_PATH, FIND_PROGRAM, or FIND_FILE command<br />
<pre><br />
FIND_FILE(BOOT_DOT_INI boot.ini PATHS [HKEY_CURRENT_USER\\Environment;HOMEDRIVE])<br />
</pre><br />
<br />
For other examples have a look in the CMake Modules folder :<br />
<pre><br />
- FindJava.cmake<br />
- FindPythonLibs.cmake<br />
- ..<br />
</pre><br />
<br />
=== How can I build my MSVC application with a static runtime? ===<br />
<br />
Here are three options you could employ to compile your MSVC application with /MT instead of /MD.<br />
<br />
==== Manual Replace ====<br />
<br />
You can rely on the user to manually modify CMAKE_C_FLAGS_DEBUG, CMAKE_C_FLAGS_RELEASE, CMAKE_CXX_FLAGS_DEBUG, CMAKE_CXX_FLAGS_RELEASE, etc. within the cache editor. After an initial configure of your software they would have to replace /MD entries with /MT.<br />
<br />
==== Make Override Files ====<br />
<br />
If you intend to build the entire source tree using /MT and you don't<br />
need this ever to be configurable via the CMake GUI, the best approach<br />
is to create an override file which initializes the starting cache<br />
values for the compile flags.<br />
<br />
First create a c_flag_overrides.cmake & cxx_flag_overrides.cmake file which<br />
contain something like this... (or whatever flags you wish to use per compiler).<br />
<br />
<pre><br />
c_flag_overrides.cmake<br />
if(MSVC)<br />
set(CMAKE_C_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")<br />
set(CMAKE_C_FLAGS_MINSIZEREL_INIT "/MT /O1 /Ob1 /D NDEBUG")<br />
set(CMAKE_C_FLAGS_RELEASE_INIT "/MT /O2 /Ob2 /D NDEBUG")<br />
set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")<br />
endif()<br />
</pre><br />
<br />
<pre><br />
cxx_flag_overrides.cmake<br />
if(MSVC)<br />
set(CMAKE_CXX_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")<br />
set(CMAKE_CXX_FLAGS_MINSIZEREL_INIT "/MT /O1 /Ob1 /D NDEBUG")<br />
set(CMAKE_CXX_FLAGS_RELEASE_INIT "/MT /O2 /Ob2 /D NDEBUG")<br />
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")<br />
endif()<br />
</pre><br />
<br />
'''NOTE:''' These files are only evaluated on the first run of CMake so they can't be dependent on a CMake option() meant to be toggled from the GUI, for example. They could be dependent on a command line -D option or an environment variable if desired.<br />
<br />
Then enable them by setting the following variables prior to the project() command.<br />
<br />
<pre><br />
set(CMAKE_USER_MAKE_RULES_OVERRIDE<br />
${CMAKE_CURRENT_SOURCE_DIR}/c_flag_overrides.cmake)<br />
set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX<br />
${CMAKE_CURRENT_SOURCE_DIR}/cxx_flag_overrides.cmake)<br />
project(Bar)<br />
</pre><br />
<br />
==== Dynamic Replace ====<br />
<br />
Alternatively, if you need dynamic control of /MT via some configure option you could use the following technique. Note: CMAKE_CXX_FLAGS_<FOO> is a directory level option, however. Also, this option has the downside of leaving /MD visible in the cache editor although it has no effect.<br />
<br />
<pre><br />
foreach(flag_var<br />
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE<br />
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)<br />
if(${flag_var} MATCHES "/MD")<br />
string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}")<br />
endif(${flag_var} MATCHES "/MD")<br />
endforeach(flag_var)<br />
</pre><br />
<br />
=== Why do generated Xcode projects have a CMake PostBuild Rules phase? ===<br />
<br />
CMake needs precise control over target link command lines that Xcode runs at build time.<br />
Xcode provides a "Link Binary With Libraries" build phase in which one may list files or products from other targets to include when linking.<br />
However, it does not allow arbitrary flags such as "<code>-lfoo</code>" commonly passed by projects to CMake's <code>target_link_libraries</code> command.<br />
It also does not allow ''full'' paths to library files and instead splits /path/to/libfoo.a into -L/path/to and -lfoo which does not guarantee the proper library will be found.<br />
<br />
CMake works around this limitation by putting the entire link line in the <code>OTHER_LDFLAGS</code> build setting where it has full control.<br />
Unfortunately that build setting is just a string, so the resulting build system has no dependency on the files named in the link line.<br />
Furthermore, Xcode does not have any build setting to list arbitrary extra dependencies of the link step.<br />
If any of a target's dependencies are newer than the target's binary Xcode does not know it needs to run the link rule again to bring the target up to date.<br />
<br />
In order to work around the dependency problem, CMake includes in each target a post-build phase that removes the link outputs of all ''other'' targets that ''depend'' on the current target.<br />
This is necessary because all those ''other'' targets lack dependencies on the current target in the generated build system.<br />
Instead when a target finishes building it knows that any other targets that depend on it will be out of date.<br />
The post-build phase removes the other targets so that when it is their turn to build Xcode will re-link them.<br />
<br />
The post-build phase could be avoided if Xcode were to simply provide a setting to specify link dependencies on arbitrary files.<br />
This feature would be useful independent of CMake as it would allow users to add dependencies on files they mention in <code>OTHER_LDFLAGS</code>.<br />
<br />
=== Why does CMake not find my Xcode compiler on OS X with the Unix Makefiles generator? ===<br />
<br />
Xcode 4.3 and later do not install the command-line development tools by default.<br />
One must also install the "Command Line Tools for Xcode" package.<br />
As of Xcode 4.4 one may install it from the Xcode menu:<br />
<pre><br />
Xcode -> Preferences -> Downloads -> Components -> Command Line Tools<br />
</pre><br />
As of Xcode 4.5 the command-line tools are also available as an independent download that does not require the full Xcode.<br />
<br />
It is also possible to set up a shell environment to run "cmake" and "make" without installing the Command Line Tools package.<br />
<br />
CMake 2.8.10 and greater will recognize when the command-line tools are not installed, find the MacOSX SDK, and add the "-isysroot" flag.<br />
One may use the environment:<br />
<br />
<pre><br />
export PATH="$(dirname $(xcrun --find make)):$PATH"<br />
export CC="$(xcrun --find cc)"<br />
export CXX="$(xcrun --find c++)"<br />
</pre><br />
<br />
The above environment will work with CMake 2.8.8 and 2.8.9 if one also specifies architectures explicitly (earlier CMake versions are not aware of Xcode 4.3+ SDKs):<br />
<br />
<pre><br />
export CMAKE_OSX_ARCHITECTURES=x86_64<br />
</pre><br />
<br />
Alternatively one may add "-isysroot" flags via the environment:<br />
<br />
<pre><br />
SDK="$(xcodebuild -sdk macosx -version Path)" &&<br />
export CFLAGS="-isysroot $SDK" &&<br />
export CXXFLAGS="-isysroot $SDK" &&<br />
unset SDK<br />
</pre><br />
<br />
== Other Questions ==<br />
<br />
=== Why does CMake generate recursive Makefiles? ===<br />
<br />
This question is often asked with reference to this paper:<br />
<br />
* Miller, Peter A., [http://miller.emu.id.au/pmiller/books/rmch/ Recursive Make Considered Harmful], AUUGN Journal of AUUG Inc., 19(1), pp. 14-25, 1998<br />
<br />
The summary of our response may be worded "recursive make considered necessary". CMake ''must'' generate makefiles that invoke other makefiles in order to implement automatic implicit dependency scanning in combination with generated source/header files. Since CMake works with primitive UNIX make tools we may not use GNU make extensions to load new make rules into an already-running make process.<br />
<br />
CMake does not actually generate truly recursive makefiles that follow the directory structure.<br />
It generates a fixed 3-level makefile structure in which each level has a defined purpose:<br />
<br />
# '''Makefile''': Command-line interface entry points. Maps "make" invocations into calls to the level 2 makefile:<br />
#* <code>make -f CMakeFiles/Makefile2 ...</code><br />
# '''CMakeFiles/Makefile2''': Inter-target dependencies. Evaluates targets in dependency order invoking for each target the depends and build steps in level 3:<br />
#* <code>make -f CMakeFiles/$(target).dir/build.make .../depend</code><br />
#* <code>make -f CMakeFiles/$(target).dir/build.make .../build</code><br />
# '''CMakeFiles/<target>.dir/build.make''': File-level dependencies and rules:<br />
#* <code>depend</code>: Evaluates custom commands (to produce generate source files) and then scans sources for implicit dependencies.<br />
#* <code>build</code>: Loads dependency scanning results from previous step. Compiles and links.<br />
<br />
<br />
As a flat-file, minimalistically-designed command-line build alternative to make, using the newly-added (2012) Ninja generator might be worthwhile.<br />
<br />
=== Why can't I make multiple targets on the command line in parallel? ===<br />
<br />
The Makefiles generated by CMake do not support explicit specification of multiple targets on the command line as<br />
<br />
<pre><br />
$ make target1 target2 -j<br />
</pre><br />
<br />
because it was not a design goal at the time the generators were written.<br />
Insead use<br />
<br />
<pre><br />
$ make target1 -j && make target2 -j<br />
</pre><br />
<br />
or use add_custom_target and add_dependencies to create a single target depending on both targets and then make that.<br />
<br />
See the multi-level makefile layout described in the answer to the [[#Why_does_CMake_generate_recursive_Makefiles.3F|above question]].<br />
It's the first level's invocation of the second level that needs to be re-worked and perhaps combined in order to fix this limitation.<br />
However, the first level is what allows one to run "make" from any subdirectory to build the targets there along with dependencies so there must be a separate Makefile in each directory.<br />
Supporting both at the same time is not a trivial change from the current design.<br />
<br />
See issue tracker entry [http://www.cmake.org/Bug/view.php?id=14312 14312].<br />
Any proposed solution must work with ancient UNIX make and cannot depend on GNU make features.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMakeForFortranExample&diff=62664CMakeForFortranExample2018-04-27T14:28:44Z<p>Brad.king: </p>
<hr />
<div>CMake is perfectly capable of handling Fortran code; however, examples are less abundant than for C or C++. In the example below we write a very small <code>CMakeLists.txt</code> to wrap a simple Fortran project. <br />
<br />
The motivation for this was to easily compile Fortran code that came with the [http://www.igs.cnrs-mrs.fr/elnemo/NORMA/ NORMA] package. The distribution NORMA-1.0.tgz was downloaded and unpacked. [[#Example CMakeLists.txt|following <tt>CMakeLists.txt</tt>]] was placed into the <tt>./software</tt> directory where the NORMA sources are stored.<br />
<br />
To build one would typically create a build directory at the same level as <tt>software</tt>:<br />
<pre><br />
mkdir build && cd build<br />
ccmake ../software<br />
make<br />
make install<br />
</pre><br />
and then configure, build and install. <br />
<br />
The project is very simple:<br />
* There are only a few fortran source code files in the software directory.<br />
* There are no library dependencies.<br />
* Executables are typically installed in a bin directory in the package itself (i.e. <tt>NORMA/bin</tt>) although the user is free to to change the installation prefix.<br />
* Two shell scripts are also installed alongside.<br />
<br />
The <tt>CMakeLists.txt</tt> is commented and [[#Comments on CMakeLists.txt|additional comments]] can be found after it.<br />
<br />
== Example CMakeLists.txt ==<br />
<pre># CMake project file for NORMA<br />
<br />
cmake_minimum_required (VERSION 2.6)<br />
project (NORMA)<br />
enable_language (Fortran)<br />
<br />
# make sure that the default is a RELEASE<br />
if (NOT CMAKE_BUILD_TYPE)<br />
set (CMAKE_BUILD_TYPE RELEASE CACHE STRING<br />
"Choose the type of build, options are: None Debug Release."<br />
FORCE)<br />
endif (NOT CMAKE_BUILD_TYPE)<br />
<br />
# default installation<br />
get_filename_component (default_prefix ".." ABSOLUTE)<br />
set (CMAKE_INSTALL_PREFIX ${default_prefix} CACHE STRING<br />
"Choose the installation directory; by default it installs in the NORMA directory."<br />
FORCE)<br />
<br />
# FFLAGS depend on the compiler<br />
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME)<br />
<br />
if (Fortran_COMPILER_NAME MATCHES "gfortran.*")<br />
# gfortran<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-funroll-all-loops -fno-f2c -O3")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-fno-f2c -O0 -g")<br />
elseif (Fortran_COMPILER_NAME MATCHES "ifort.*")<br />
# ifort (untested)<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-f77rtl -O3")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-f77rtl -O0 -g")<br />
elseif (Fortran_COMPILER_NAME MATCHES "g77")<br />
# g77<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-funroll-all-loops -fno-f2c -O3 -m32")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-fno-f2c -O0 -g -m32")<br />
else (Fortran_COMPILER_NAME MATCHES "gfortran.*")<br />
message ("CMAKE_Fortran_COMPILER full path: " ${CMAKE_Fortran_COMPILER})<br />
message ("Fortran compiler: " ${Fortran_COMPILER_NAME})<br />
message ("No optimized Fortran compiler flags are known, we just try -O2...")<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-O2")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-O0 -g")<br />
endif (Fortran_COMPILER_NAME MATCHES "gfortran.*")<br />
<br />
<br />
# build executables<br />
set (NMPROGRAMS "diagstd" "diagrtb" "proj_modes_bin" "pdbmat")<br />
set (EXECUTABLES "NORMA.exe" ${NMPROGRAMS})<br />
set (SCRIPTS "gen_pert.sh" "pert_multi_mode.sh")<br />
<br />
add_executable ("NORMA.exe" "NORMA.f")<br />
foreach (p ${NMPROGRAMS})<br />
add_executable (${p} "${p}.f")<br />
endforeach (p)<br />
<br />
# install executables and scripts<br />
install (TARGETS ${EXECUTABLES} <br />
RUNTIME DESTINATION "bin")<br />
install (PROGRAMS ${SCRIPTS}<br />
DESTINATION "bin") <br />
</pre><br />
<br />
== Comments on CMakeLists.txt ==<br />
* Use cmake v2.6 or better for [[CMake Fortran Issues|optimum Fortran support]].<br />
* Make sure that we build a RELEASE by default (and let the user know in the GUI); uses example code from the docs.<br />
* Set the default prefix to the non-standard installation scheme in which one installs all component into the package directory. This directory is assumed to be one above relative the build directory. The full canonical path is obtained with the [http://www.cmake.org/cmake/help/cmake2.6docs.html#command:get_filename_component get_filename_component] function.<br />
* As it is typical for scientific Fortran code, the compiler optimizations are fairly specific. Here we are trying to detect a few common ones (gfortran, Intel ifort, g77) and set the compile options accordingly. If all else fails we use -O2 and hope for the best (but let the user know).<br />
* The <tt>NORMA.exe</tt> binary is built from the source <tt>NORMA.f</tt> so we have to say this explicitly with the <pre>add_executable ("NORMA.exe" "NORMA.f")</pre>line but the other binaries are simply built from corresponding .f files and we write this as a simple foreach-loop.<br />
* Executables are installed in the <tt>bin</tt> dir (which is relative to the prefix).<br />
* Finally, scripts are copied to the <tt>bin</tt> directory, too.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake:Packaging_With_CPack&diff=62663CMake:Packaging With CPack2018-04-27T14:27:33Z<p>Brad.king: </p>
<hr />
<div><!-- CPack documentation and manual --><br />
=Introduction=<br />
<br />
''CPack'' is a powerful, easy to use, cross-platform software packaging tool distributed with [http://www.cmake.org CMake] since version 2.4.2. It uses the [[CMake:CPackPackageGenerators|generators]] concept from CMake, to abstract package generation on specific platforms, and it can be used with or without CMake.<br />
<br />
Using either a simple configuration file or the CMake module, a complex project can be packaged into an installer.<br />
<br />
=Using CPack without CMake=<br />
<br />
CPack can be used directly by specifying a CPackConfig.cmake file, which uses CMake syntax and defines several variables. Here is an example CPackConfig.cmake file for a Linux system:<br />
<br />
<pre><nowiki>SET(CPACK_CMAKE_GENERATOR "Unix Makefiles")<br />
SET(CPACK_GENERATOR "STGZ;TGZ;TZ")<br />
SET(CPACK_INSTALL_CMAKE_PROJECTS "/home/andy/vtk/CMake-bin;CMake;ALL;/")<br />
SET(CPACK_NSIS_DISPLAY_NAME "CMake 2.5")<br />
SET(CPACK_OUTPUT_CONFIG_FILE "/home/andy/vtk/CMake-bin/CPackConfig.cmake")<br />
SET(CPACK_PACKAGE_DESCRIPTION_FILE "/home/andy/vtk/CMake/Copyright.txt")<br />
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "CMake is a build tool")<br />
SET(CPACK_PACKAGE_EXECUTABLES "ccmake;CMake")<br />
SET(CPACK_PACKAGE_FILE_NAME "cmake-2.5.0-Linux-i686")<br />
SET(CPACK_PACKAGE_INSTALL_DIRECTORY "CMake 2.5")<br />
SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "CMake 2.5.0")<br />
SET(CPACK_PACKAGE_NAME "CMake")<br />
SET(CPACK_PACKAGE_VENDOR "Kitware")<br />
SET(CPACK_PACKAGE_VERSION "2.5.0")<br />
SET(CPACK_PACKAGE_VERSION_MAJOR "2")<br />
SET(CPACK_PACKAGE_VERSION_MINOR "5")<br />
SET(CPACK_PACKAGE_VERSION_PATCH "0")<br />
SET(CPACK_RESOURCE_FILE_LICENSE "/home/andy/vtk/CMake/Copyright.txt")<br />
SET(CPACK_RESOURCE_FILE_README "/home/andy/vtk/CMake/Templates/CPack.GenericDescription.txt")<br />
SET(CPACK_RESOURCE_FILE_WELCOME "/home/andy/vtk/CMake/Templates/CPack.GenericWelcome.txt")<br />
SET(CPACK_SOURCE_GENERATOR "TGZ;TZ")<br />
SET(CPACK_SOURCE_OUTPUT_CONFIG_FILE "/home/andy/vtk/CMake-bin/CPackSourceConfig.cmake")<br />
SET(CPACK_SOURCE_PACKAGE_FILE_NAME "cmake-2.5.0")<br />
SET(CPACK_SOURCE_STRIP_FILES "")<br />
SET(CPACK_STRIP_FILES "bin/ccmake;bin/cmake;bin/cpack;bin/ctest")<br />
SET(CPACK_SYSTEM_NAME "Linux-i686")<br />
SET(CPACK_TOPLEVEL_TAG "Linux-i686")</nowiki></pre><br />
<br />
These variables can also be overwritten on the command line using the option "-D":<br />
<br />
<pre><br />
cpack -D CPACK_PACKAGE_VENDOR=Me -D CPACK_SYSTEM_NAME=super-duper-linux ...<br />
</pre><br />
<br />
<br />
=Using CPack with CMake=<br />
<br />
CMake comes with a CPack module, which will automatically generate an appropriate CPack configuration file. To use the module, simply invoke the following command (BTW, failure to do so will result in an annoying "CPack Error: CPack project name not specified" message...):<br />
<br />
<pre><nowiki>INCLUDE(CPack)</nowiki></pre><br />
<br />
This generates a new target called ''"package"'' in your build system. When this target is built, CPack will be invoked to generate all of the packages. Internally, CPack will use [[CMake:Install_Commands | CMake's install mechanism]] to automatically populate the package.<br />
<br />
An example output of the ''"package"'' target (from a Linux Makefile) is:<br />
<br />
<pre><nowiki>Run CPack packaging tool...<br />
CPack: Create package using STGZ<br />
CPack: Install projects<br />
CPack: - Run preinstall target for: CMake<br />
CPack: - Install project: CMake<br />
CPack: - Strip files<br />
CPack: Compress package<br />
CPack: Finalize package<br />
CPack: Package /home/andy/CMake-bin/cmake-2.5.0-Linux-i686.sh generated.<br />
CPack: Create package using TGZ<br />
CPack: Install projects<br />
CPack: - Run preinstall target for: CMake<br />
CPack: - Install project: CMake<br />
CPack: - Strip files<br />
CPack: Compress package<br />
CPack: Finalize package<br />
CPack: Package /home/andy/CMake-bin/cmake-2.5.0-Linux-i686.tar.gz generated.<br />
CPack: Create package using TZ<br />
CPack: Install projects<br />
CPack: - Run preinstall target for: CMake<br />
CPack: - Install project: CMake<br />
CPack: - Strip files<br />
CPack: Compress package<br />
CPack: Finalize package<br />
CPack: Package /home/andy/CMake-bin/cmake-2.5.0-Linux-i686.tar.Z generated.</nowiki></pre><br />
<br />
<br />
==Using CMake variables to configure CPack==<br />
<br />
To configure CPack, it is possible to define [[CMake:CPackConfiguration| CPack variables]] inside a CMake file. These variables will be copied across to the generated CPackConfig.cmake file before CPack is invoked.<br />
<br />
This is an example CMake list section for CPack configuration:<br />
<br />
<pre><nowiki><br />
INCLUDE(InstallRequiredSystemLibraries)<br />
<br />
SET(CPACK_PACKAGE_DESCRIPTION_SUMMARY "My funky project")<br />
SET(CPACK_PACKAGE_VENDOR "Me, myself, and I")<br />
SET(CPACK_PACKAGE_DESCRIPTION_FILE "${CMAKE_CURRENT_SOURCE_DIR}/ReadMe.txt")<br />
SET(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/Copyright.txt")<br />
SET(CPACK_PACKAGE_VERSION_MAJOR "1")<br />
SET(CPACK_PACKAGE_VERSION_MINOR "3")<br />
SET(CPACK_PACKAGE_VERSION_PATCH "2")<br />
SET(CPACK_PACKAGE_INSTALL_DIRECTORY "CMake ${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}")<br />
IF(WIN32 AND NOT UNIX)<br />
# There is a bug in NSI that does not handle full unix paths properly. Make<br />
# sure there is at least one set of four (4) backlasshes.<br />
SET(CPACK_PACKAGE_ICON "${CMake_SOURCE_DIR}/Utilities/Release\\\\InstallIcon.bmp")<br />
SET(CPACK_NSIS_INSTALLED_ICON_NAME "bin\\\\MyExecutable.exe")<br />
SET(CPACK_NSIS_DISPLAY_NAME "${CPACK_PACKAGE_INSTALL_DIRECTORY} My Famous Project")<br />
SET(CPACK_NSIS_HELP_LINK "http:\\\\\\\\www.my-project-home-page.org")<br />
SET(CPACK_NSIS_URL_INFO_ABOUT "http:\\\\\\\\www.my-personal-home-page.com")<br />
SET(CPACK_NSIS_CONTACT "me@my-personal-home-page.com")<br />
SET(CPACK_NSIS_MODIFY_PATH ON)<br />
ELSE(WIN32 AND NOT UNIX)<br />
SET(CPACK_STRIP_FILES "bin/MyExecutable")<br />
SET(CPACK_SOURCE_STRIP_FILES "")<br />
ENDIF(WIN32 AND NOT UNIX)<br />
SET(CPACK_PACKAGE_EXECUTABLES "MyExecutable" "My Executable")<br />
INCLUDE(CPack)</nowiki></pre><br />
<br />
== CPack Generators ==<br />
There are several [[CMake:CPackPackageGenerators|generators]] usable with CPack.<br />
<br />
=Example=<br />
Here is an [[CMake/CPack/Examples/Linux/DEB|example]].<br />
<br />
=Debugging=<br />
A very detailed log of CPack execution steps can be obtained via cpack --debug --verbose (which, as a side note, are features that are awfully hidden at least in older versions of CPack).<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62662CMake2018-04-27T14:24:49Z<p>Brad.king: /* Success Stories */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake_HowToDoPlatformChecks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake/Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving_Find*_Modules]]<br />
* [[CMake/C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62661CMake2018-04-27T14:22:54Z<p>Brad.king: /* More Topics */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake_HowToDoPlatformChecks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving_Find*_Modules]]<br />
* [[CMake/C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62660CMake2018-04-27T14:22:09Z<p>Brad.king: /* More Topics */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake_HowToDoPlatformChecks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving Find* Modules ]]<br />
* [[CMake/C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62659CMake2018-04-27T14:20:58Z<p>Brad.king: /* General */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake_HowToDoPlatformChecks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving Find* Modules ]]<br />
* [[C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62658CMake2018-04-27T14:20:14Z<p>Brad.king: /* More Topics */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake HowToDoPlatformChecks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving Find* Modules ]]<br />
* [[C_Plugins_for_Loadable_Commands]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake&diff=62657CMake2018-04-27T14:19:36Z<p>Brad.king: /* Tutorials */</p>
<hr />
<div>{{CMake/Template/Header}}<br />
<br />
https://cmake.org/cmake/img/CMake-logo-download.jpg<br />
<br />
<!-- documentation manual man information help tutorial --><br />
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.<br />
<br />
You will find here not only documentation for CMake, but also for CPack and CTest.<br />
=CMake=<br />
<br />
==Primary Resources - Look here first! ==<br />
* Where can I [https://cmake.org/HTML/Download.html download CMake]?<br />
* [https://cmake.org/documentation/ CMake Documentation]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html Structure of a CMake Build System]<br />
* [[CMake FAQ| FAQ (Frequently asked questions)]]<br />
* [https://cmake.org/mailman/listinfo/cmake CMake Mailing List] (for searchable archives see [[CMake_FAQ#Where_can_I_find_searchable_CMake_Mailing_Archives | CMake FAQ ]])<br />
* [[https://cmake.org/cmake/help/latest/release/index.html|CMake Release Notes]]<br />
<br />
==Reference Material==<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html CMake Variables]<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html?highlight=properties List of CMake Properties] <br />
====The CMake Language====<br />
* [https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#syntax A quick introduction to CMake syntax]<br />
* [[CMake:VariablesListsStrings| On variables, lists, strings, maps, regexps, etc.]]<br />
* [[CMake/Language Syntax | Language syntax]]<br />
<br />
==Guides==<br />
====General====<br />
* [[CMake Cross Compiling| Cross compiling]]<br />
* [[CMake HowToDoPlatformChecks| How to write platform checks with CMake]]<br />
* [[CMake:How_To_Find_Libraries | How to find libraries]]<br />
* [[CMake:Install Commands| How to install things]]<br />
<br />
====Specific====<br />
* [[CMake RPATH handling|RPATH handling]]<br />
* [[CMake Editors Support|Editors/IDEs with CMake syntax support]]<br />
* [[BuildingWinDLL| How to export symbols from a Windows DLL for the non-Windows Developer]]<br />
* [[RecipeAddSoVersionToDLLs|Appending the SO version to DLLs]]<br />
* [[CMake_Build_Rules | Advanced Usage of CMake Build Rules]]<br />
* [[CMake_Checking_Platform | How to Check the Current Platform]]<br />
<br />
==Development Topics==<br />
* [[CMake/Assembler|Assembler Support]]<br />
* [[CMake Generator Specific Information|Docs for Specific Project Generators]] (Eclipse, KDevelop3, CodeBlocks, Makefile)<br />
* [[CMake User Contributed Macros| Contributed macros]]<br />
* [[CMake:Module Maintainers|Module Maintainers]]<br />
* [[CMake Platform Dependent Issues|Platform Dependent Information]]<br />
* [[CMake/ChangeLog|Current CMake Version ChangeLog]]<br />
* [[CMake Released Versions|Documentation for previous releases]]<br />
* [[CMake Life Cycle Considerations]]<br />
* [[CMake Version Compatibility Matrix|Matrix for checking backwards-compatibility of current features]]<br />
* [[CMake builtin documentation handling]]<br />
* [http://www.aosabook.org/en/cmake.html The architecture of Open Source Applications - CMake]<br />
<br />
==Tutorials==<br />
<br />
===Basic Introductions===<br />
* [https://cmake.org/HTML/Examples.html A Simple CMake Example]<br />
* [http://www.linuxjournal.com/article/6700 Cross-Platform Software Development Using CMake]<br />
* [http://clubjuggler.livejournal.com/138364.html CMake: The Cross Platform Build System]<br />
* [http://www.elpauer.org/stuff/learning_cmake.pdf "Learning CMake"] - Slides of a CMake workshop, including CPack, CTest and CDash<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides (with LaTeX bearmer source) of a CMake tutorial including CPack, CTest.<br />
* [http://www.visgraf.impa.br/seminar/slides/rodlima_cmake_presentation.pdf "CMake: Behind the Scenes of Code Development"] - Slides of an introductory talk/tutorial about CMake and its benefits<br />
* [http://hackerwithin.org/thw/plugin_wiki/page/buildsystems The Hacker Within: Build Systems] Explains why and how to use build systems with a CMake example.<br />
<br />
* How CMake simplifies the build process by Bruno Abinader<br />
** [https://brunoabinader.com/how-cmake-simplifies-the-build-process-part-1-basic-build-system Part 1 - Basic build system]<br />
** [http://web.archive.org/web/20101030232202/http://cabledogs.org/abinader/2009/12/09/how-cmake-simplifies-the-build-process-part-2-advanced-build-system/ Part 2 - Advanced build system]<br />
* [http://rachid.koucha.free.fr/tech_corner/cmake_manual.html Empirical approach to CMAKE] by Rachid Koucha<br />
* [[CMake/MinimalExamples | Minimal examples]] (wiki page)<br />
<br />
===Finding stuff and platform checking===<br />
<br />
* [[CMake/Tutorials#CMake_Packages|How to package your project for use by others]], create FooConfig.cmake files, and exporting and importing targets.<br />
<br />
* [[CMake:HowToUseExistingOSXFrameworks | How to find and use existing frameworks on OS X]]<br> A quick example to help OS X users find frameworks automatically.<br />
<br />
===How to use CMake with specific Libraries ===<br />
<br />
* [[CMake:How To Build Qt4 Software | How to build Qt4 software with CMake]]<br />
<br />
* [http://qtnode.net/wiki?title=Qt_with_cmake Qt with CMake] <br>Explains how to use CMake to build software with Qt4, Qt3 and KDE3.<br />
<br />
* [http://mikemcquaid.com/2012/01/deploying-qt-applications-with-deployqt4/ Deploying Qt4 applications with CMake] <br>Explains how to use the DeployQt4.cmake module coming with CMake 2.8.7.<br />
<br />
* [[CMake:How To Build KDE4 Software | How to build KDE4 software with CMake]]<br />
<br />
* [[CMake/MatlabMex | How to use CMake to create Matlab MEX files]] <br> Describes how to use CMake when developing Matlab Executable (MEX) files for use with The Mathworks Matlab scripting language.<br />
<br />
* [http://www.wxwidgets.org/wiki/index.php/CMake How to use CMake for building software with wxWidgets ]<br />
<br />
* [http://www.linuxdevices.com/articles/AT6762290643.html Building eCos applications with CMake]<br />
<br />
* [http://www.smslana.eu Building Sms applications with CMake]<br />
<br />
* [http://blog.quickforge.co.uk/2011/10/exploration-of-cross-compiling-on-windows-for-arm-linux-distributions/ Cross compiling from Windows to ARM Linux]<br />
<br />
* [[CMakeForFLTK| Using CMake to build an FLTK application]]<br />
<br />
===Recipes===<br />
<br />
* [[CMake:How To Process Lots Of Input Files | How to process lots of input files with a processor built by CMake]]<br />
<br />
<br />
* [[VSConfigSpecificSettings| Configuration Specific Settings for Visual Studio Generated Project Files]]<br />
<br />
* [[BundleUtilitiesExample| How to use the 'BundleUtilities' to deploy your OS X Application. Example uses Qt 4.]]<br />
<br />
* [[CMakeForFortranExample|How to write a simple CMakeLists.txt for Fortran code]]<br />
<br />
* [[CMakeEmulateMakeCheck|How to emulate GNU Autotools 'make check']]<br />
<br />
* [[CustomCommandCustomTargetInstall|A toy model for add_custom_command and add_custom_target]]<br />
<br />
* [[CMake:OSX_InterfaceBuilderFiles|Working with OS X Interface Builder Files]]<br />
<br />
* [[RecipeAppendVersionNumberToInstallpath|Append the Version Number to the Install path]]<br />
<br />
* [[RecipeInstallToALocalFolderForTesting|Install to a local folder in the build dir for testing]]<br />
<br />
* [[RecipeAddUninstallTarget|Adding an uninstall target to your project]]<br />
<br />
<br />
==Converters from other buildsystems to CMake==<br />
<br />
All converters listed here are not "complete", i.e. the generated CMake files are not 100% finished, in all cases some work is left for the developer.<br />
<br />
====automake/autotools/autoconf====<br />
* [https://projects.kde.org/projects/kde/kdesdk/kde-dev-scripts/repository/revisions/master/changes/cmake-utils/scripts/am2cmake am2cmake (requires Ruby) ] Converts automake/autotools/libtool based projects to CMake, specialized in converting from KDE 3 to KDE 4, should also work for others. This one has been used for converting the KDE buildsystem to CMake.<br />
<br />
* [http://emanuelgreisen.dk/stuff/kdevelop_am2cmake.php.tgz Alternative Automake2CMake (requires PHP)] Converts KDevelop projects that use automake to CMake.<br />
<br />
* [[GccXmlAutoConfHints|Converting autoconf tests]]<br />
<br />
====qmake====<br />
* [[CMake:ConvertFromQmake | qmake converter (requires Ruby)]] Converts projects that use Qt's qmake.<br />
<br />
====Visual Studio====<br />
* [http://vcproj2cmake.sf.net vcproj2cmake.rb (requires Ruby) SourceForge project] Creates '''and maintains''' CMakeLists.txt files by extracting info from Visual Studio project files (.vcproj/.vcxproj). Elaborate script for development side-by-side the updated original static .vc[x]proj files, supports script hooks and powerful definition mappings. Patches and new project members very welcome. Older script versions below:<br />
** [http://www.eskilson.se/vcproj2cmake.rb Original vcproj2cmake.rb version (requires Ruby)] <br />
** Slightly newer version here [http://dgwarp.hd.free.fr/vcproj2cmake.rb vcproj2cmake.rb], see:[[User_talk:Dweeves]] for details<br />
* [http://nberserk.blogspot.com/2010/11/converting-vc-projectsvcproj-to.html vcproj2cmake.ps1(PowerShell version)] Creates CMakeLists.txt. it supports vcproj configuration and detect 'exclude from build' option<br />
* [http://sourceforge.net/projects/folders4cmake/ folders4cmake (requires Java)] Use Visual Studio project files to generate corresponding "source_group" information that you can use inside your own CMake scripts. Supports Visual Studio 9/10 project files (full round-trip possible).<br />
<br />
====Basic CMakeLists.txt from-scratch-generator====<br />
* [http://websvn.kde.org/trunk/KDE/kdesdk/cmake/scripts/ gencmake (requires Ruby) ] Creates basic CMakeLists.txt files from looking at the existing files.<br />
* [http://www.vanvelzensoftware.com/postnuke/index.php?name=Downloads&req=viewdownload&cid=7 CMakeListGenerator (Win32) ] Creates complete CMakeLists.txt files as described in the [https://gucef.svn.sourceforge.net/svnroot/gucef/trunk/tools/CMakeListGenerator/docs/README.txt README ] using a combination of file and directory structure analysis. Supports resolving dependencies between multiple archives.<br />
<br />
==Success Stories==<br />
<br />
* What are some [[CMake Projects|projects using CMake]]?<br />
* [[CMake:Articles|Articles about CMake]]<br />
* [[Really Cool CMake Features]]<br />
<br />
<br />
==More Topics==<br />
<br />
* [[CMake Fortran Issues|Fortran Issues]]<br />
* [[CMake:For CMake Hackers|Generating dependency graphs with CMake]]<br />
* [[CMake:Experiments With Lua|Experiments With Lua]]<br />
* [[CMake Performance Tips|Performance Tips]]<br />
* [[CMake:GNU style example | GNU style directory layout with CMake]]<br />
* [[CMake:OpenTasks| CMake TODO]]<br />
* [[CMake:CreateQtAssistantDocs| Creating Qt Assistant Docs]]<br />
* [[CMake:Static libraries| Writing FindXXX.cmake modules that work with static libraries]]<br />
* [[CMake:Multiple versions| Writing FindXXX.cmake modules that work when multiple versions of packages are installed]]<br />
* [[CMake:Improving Find* Modules ]]<br />
* [[/C Plugins for Loadable Commands/]]<br>For anyone who wonders what the <tt>load_command</tt> command is for.<br />
* [[PC-Lint]] support for CMake<br />
<br />
=CTest=<br />
<br />
===Tutorials===<br />
* [[CMake/Testing_With_CTest|Testing With CTest]]<br>Introduces to testing with CTest, submitting dashboards, and using CMake to add tests to the test system.<br />
<br />
* [[CMake_Scripting_Of_CTest|CTest Scripting]]<br>Describes the scripting with CTest which can significantly simplify and automate testing and submitting dashboards.<br />
<br />
* [[CMake_Generating_Testing_Files|Generating Input Files For CTest]]<br>Describe more in details the concepts behind testing with CTest and also explans how to use CTest without using CMake.<br />
<br />
* [[CTest:Buildserver|Buildmanagement With CTest]]<br>Describes how to setup a central configuration for all CTest scripts.<br />
<br />
===More Information===<br />
* [[CTest:Submission Issues|Configuring CTest Submission Methods]]<br />
* [[CTest:Nightly, Experimental, Continuous|CTest Nightly, Experimental, Continuous, ...]]<br />
* [[CTest:Coverage]]<br />
* [[Media:CTest Running Modes.pdf]]<br />
* [[CTest:FAQ|CTest Frequently asked questions]]<br />
<br />
===More Topics===<br />
* [[CTest:OpenTasks| CTest TODO]]<br />
* [[CTest:TestWithoutBuild| Run tests on machines without building first]]<br />
<br />
=CDash=<br />
* [http://public.kitware.com/Wiki/CDash CDash Wiki].<br />
* [http://public.kitware.com/Wiki/CDash:FAQ CDash FAQ].<br />
<br />
<br />
=CPack=<br />
===Tutorials===<br />
* [[CMake:Packaging With CPack|Packaging with CPack]]<br>Introduction to CPack, installing and packaging of software.<br />
* [https://github.com/TheErk/CMake-tutorial CMake tutorial] - Slides from a CMake tutorial (including LaTeX beamer source) including CPack.<br />
* [[CMake:CPackConfiguration|CPack Variables]]<br />
* [[CMake:CPackPackageGenerators|Supported package formats]]<br />
* [[CMake:CPackWin32NewbiesChecklist|CPack Win32 Newbie Checklist]]<br />
* [[CMake:Component_Install_With_CPack|Component Install With CPack]]<br />
<br />
===Recipes===<br />
<br />
* [[RecipeAddShortcutToStartMenu|Add an application shortcut to the Start Menu]]<br />
<br />
<br />
=Old(deprecated) kept for reference only=<br />
<br />
* [[CMake_2.6_Notes|CMake 2.6 Notes]]<br />
* [[CMake Useful Variables|Useful CMake Variables]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake_Generating_Testing_Files&diff=62656CMake Generating Testing Files2018-04-27T14:17:38Z<p>Brad.king: /* Using CMake */</p>
<hr />
<div>==Introduction==<br />
<br />
CTest is a powerful testing client compatible with<br />
[http://public.kitware.com/Dart Dart] Dashboard system. It is distributed as a<br />
part of [http://www.cmake.org CMake] but can be used with or without CMake.<br />
This tutorial explains some background behind the testing with CTest and the<br />
process of generating CTest testing files.<br />
<br />
==CTest Overview==<br />
<br />
CTest currently uses the old Dart input configuration file. New input format is<br />
being developed, but the old format will be valid in the future. For legacy<br />
purposes, the input files are called ''DartConfiguration.tcl'', and<br />
''DartTestfile.txt''. ''DartConfiguration.tcl'' describes the system on which<br />
tests are performed, while ''DartTestfile.txt'' provides the list of tests.<br />
<br />
CTest reads ''DartConfiguration.tcl'' and depending on the options provided it<br />
performs certain stage of testing.<br />
<br />
===Description Of The System===<br />
<br />
Even though the extension of ''DartConfiguration.tcl''<br />
file is ''.tcl'', it is not TCL file. It is simply list of key/value pairs.<br />
Line starting with ''#'' are considered comments and are ignored. This file has to appear at the toplevel directory of the project's build directory.<br />
<br />
Example ''DartConfiguration.tcl'' file is:<br />
<br />
<pre><br />
SourceDirectory: /path/to/project/source/directory<br />
BuildDirectory: /path/to/project/build/directory<br />
CVSUpdateOptions: -d -A -P<br />
Site: my-system-name<br />
BuildName: build-name<br />
DropSite: public.kitware.com<br />
DropLocation: /cgi-bin/HTTPUploadDartFile.cgi <br />
DropMethod: http<br />
TriggerSite: http://public.kitware.com/cgi-bin/Submit-Random-TestingResults.pl<br />
NightlyStartTime: 21:00:00 EDT<br />
ConfigureCommand: "/path/to/source/directory/Project/configure"<br />
MakeCommand: /usr/bin/make -i<br />
CVSCommand: /usr/bin/cvs<br />
CoverageCommand: /usr/bin/gcov<br />
TimeOut: 1500<br />
</pre><br />
<br />
====DartConfiguration.tcl options====<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Key !! Description !! Example value<br />
|-<br />
| SourceDirectory || Path to the source directory of the project. Used for CVS or SVN update. || /path/to/project/source/directory<br />
|-<br />
| BuildDirectory || Path to the build directory of the project. This is where Testing results will go and all testing commands will be run in this directory. || /path/to/project/build/directory<br />
|-<br />
| Site || Refers to the system name used to distinguish the dashboard entry. || my-system-name<br />
|-<br />
| BuildName || A breif description of the system and the project. || FLTK-Linux-g++334<br />
|-<br />
| DropSite ||rowspan=4| ''DropSite'', ''DropLocation'', ''DropMethod'', and ''TriggerSite'' describe the location where test results are submitted. For more information about CTest submission, please look at: [[CTest:Submission_Issues]]. The location specified in the example is the [http://public.kitware.com/dashboard.php?name=public Public Dashboard] provided as a service by [http://www.kitware.com Kitware]. || public.kitware.com<br />
|-<br />
| DropLocation|| /cgi-bin/HTTPUploadDartFile.cgi <br />
|-<br />
| DropMethod || http<br />
|-<br />
| TriggerSite || http://public.kitware.com/cgi-bin/Submit-Random-TestingResults.pl<br />
|-<br />
| NightlyStartTime ||A the time when Nightly dashboard starts. This is useful when doing Nightly dashboard. The Nightly dashboard will update the source directory to the state at given time. || 21:00:00 EDT<br />
|-<br />
| UpdateCommand || Command used to update the project during the Update stage. || /usr/bin/cvs<br />
|-<br />
| UpdateOptions || Additional options passed to update command || -d -A -P<br />
|-<br />
| UpdateType || Type of update used. Currently only CVS and SVN are valid types || cvs<br />
|-<br />
| ConfigureCommand || Command run during the Configure stage || "/path/to/source/directory/Project/configure"<br />
|-<br />
| MakeCommand || Command run during the Build stage ||/usr/bin/make -i<br />
|-<br />
| CoverageCommand || Command used for the Coverage testing. Currently only GCC gcov is supported. || /usr/bin/gcov<br />
|-<br />
| TimeOut || A maximum time the test will be allowed to run. Once test time expires, the test will be interrupted and the status will be ''Timeout''. ||1500<br />
|}<br />
<br />
===Description of Tests===<br />
<br />
For legacy purposes and for compatibility with ''Dart'', the test description<br />
file is called ''DartTestfile.txt''. It is parsed by full CMake parser, but the<br />
only CMake commands that are available are ''SUBDIRS'' and ''ADD_TEST''. Example<br />
''DartTestfile.txt'' is:<br />
<br />
<pre><br />
ADD_TEST(testProcess-1 "/my/project/testProcess" "1")<br />
ADD_TEST(testProcess-2 "/my/project/testProcess" "2")<br />
ADD_TEST(testProcess-3 "/my/project/testProcess" "3")<br />
ADD_TEST(testProcess-4 "/my/project/testProcess" "4")<br />
ADD_TEST(testProcess-5 "/my/project/testProcess" "5")<br />
ADD_TEST(testProcess-6 "/my/project/testProcess" "6")<br />
</pre><br />
<br />
Each of the ''ADD_TEST'' adds the test for CTest. The first argument is the<br />
unique name of test. It should be unique, so that it can be differentiated<br />
among all results. The second argument is the executable run as a part of the<br />
test. This is followed by arbitrary number of arguments for the executable.<br />
Test executables can be built as a part of the project (via add_executable), <br />
or a system executable can be used. For example, to test a ''Python'' feature:<br />
<br />
<pre><br />
ADD_TEST(testTkInter "/usr/bin/python" "-c" "import Tkinter")<br />
</pre><br />
<br />
It is a good practice to specify full path to the executable name, since that<br />
way CTest will always pick the desired executable. For example, let say the<br />
test executable name is ''python'' but there is a python installed on the<br />
system, the CTest may pick either the ''python'' executable built by our build<br />
process or use the installed one.<br />
<br />
===Group Tests in Subdirectories===<br />
<br />
Project tests are usually organized into some structure based on the part of the project they test. For example, if the project contains some common code, IO code, processing code, and GUI code, there may be group of tests for each subsection. Common way of organizing this would be in subdirectories. For example, let say the project has the following directory structure:<br />
<br />
<pre><br />
/Project<br />
/Common<br />
/IO<br />
/Processing<br />
/GUI<br />
</pre><br />
<br />
It is fairly easy to reproduce this structure for testing:<br />
<br />
<pre><br />
/Project<br />
/Testing<br />
/Common<br />
/IO<br />
/Processing<br />
/GUI<br />
</pre><br />
<br />
CTest will not automatically search all subdirectories and find all<br />
''DartTestfile.txt''. The project needs to tell it where the tests are. This<br />
can be achieved using ''SUBDIRS'' command in ''DartTestfile.txt''. An example use of ''SUBDIRS'' command is:<br />
<br />
<pre><br />
SUBDIRS(Testing/Common)<br />
SUBDIRS(Testing/IO)<br />
SUBDIRS(Testing/Processing Testing/GUI)<br />
</pre><br />
<br />
The arguments to the ''SUBDIRS'' command are subdirectories containing the<br />
tests. If this file is placed in the top of our project, CTest will search for<br />
files ''DartTestfile.txt'' inside directories /.../Project/Testing/Common,<br />
/.../Project/Testing/IO, and so on to /.../Project/Testing/GUI.<br />
<br />
==Generating Testing Files==<br />
<br />
Testing files ''DartConfiguration.tcl'' and all ''DartTestfile.txt' must be<br />
generated in the same tree as the CTest is run. In most cases this is the build<br />
tree of the project. Since the testing files contain build and system specific<br />
information, they should be generated as a part of testing process and not<br />
permanently part of source code.<br />
<br />
===Using CMake===<br />
<br />
CMake has a automated way of generating CTest input files. There are three pieces to performing testing:<br />
<br />
<pre><br />
ENABLE_TESTING()<br />
</pre><br />
<br />
Enables testing for the project. This command will gather all tests and produce<br />
''DartTestfile.txt'' files with appropriate ''ADD_TEST'' and ''SUBDIRS''<br />
commands.<br />
<br />
<pre><br />
INCLUDE(Dart)<br />
</pre><br />
<br />
Including ''Dart'' CMake module will generate default ''DartConfiguration.tcl''<br />
file, which will contain information about updating, configuring, and building<br />
the project.<br />
<br />
<pre><br />
ADD_TEST(test1 ${EXECUTABLE_OUTPUT_PATH}/test1)<br />
</pre><br />
<br />
Describes test that will be put in ''DartTestfile.txt''. The syntax of ADD_TEST on CMake level is the same as once it is written in ''DartTestfile.txt''. <br />
<br />
More details about how to generate test files with CMake is described in<br />
[[CMake/Testing_With_CTest|Testing With CTest]] tutorial.<br />
<br />
===Without Using CMake===<br />
<br />
CTest is distributed together with CMake, but it can be used independently. The<br />
''DartConfiguration.tcl'' file can be easily generated using ''autoconf'' or<br />
any other tool, or even written by hand. Whatever the method of generating that<br />
file, the author has to make sure all the necessary information is written in<br />
it. Same goes for ''DartTestfile.txt'' files.<br />
<br />
==Conclusion==<br />
<br />
Though we consider CMake to be a great build configuration tool, CTest can be<br />
used without CMake. Because of its simplicity, it can be added to any project<br />
without changing the rest of the project development. Using a small number of<br />
configuration files, CTest can easily automate most if not all of the commonly<br />
used testing procedures.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake_Scripting_Of_CTest&diff=62655CMake Scripting Of CTest2018-04-27T14:16:44Z<p>Brad.king: /* Testing With CTest */</p>
<hr />
<div>==Testing With CTest==<br />
<br />
In [[CMake/Testing_With_CTest|Testing With CTest]], you learned how to<br />
use CTest to perfom simple testing. That page also describes how to use<br />
CTest to submit dashboards. The typical sequence of commands that<br />
dashboard contributor will do involves:<br />
<br />
<pre><br />
cd /location/of/binary/Directory<br />
rm -rf BinaryDirectory<br />
mkdir BinaryDirectory<br />
cd BinaryDirectory<br />
ccmake /location/of/source/Directory<br />
ctest -D Nightly<br />
</pre><br />
<br />
This is done on a typical UNIX system. On Windows system, the<br />
contributor needs to do something similar using Windows command<br />
interpreter, using something like Cygwin, or using a scripting language<br />
such as Perl, Python, or Tcl. Unfortunately none of these solutions is<br />
portable.<br />
<br />
==CTest Scripting==<br />
<br />
CTest has a built-in scripting mode, which significantly simplifies<br />
generating dashboards. Here is example of this script:<br />
<br />
<pre><br />
SET (CTEST_SOURCE_DIRECTORY "C:/Hoffman/My Builds/CMake")<br />
SET (CTEST_BINARY_DIRECTORY "C:/Hoffman/My Builds/CMakeVSNMake71")<br />
<br />
SET (CTEST_CVS_COMMAND "C:/cygwin/bin/cvs.exe")<br />
SET (CTEST_CVS_CHECKOUT "${CTEST_CVS_COMMAND} -d:pserver:hoffman@www.cmake.org:/cvsroot/CMake co -d\"${CTEST_SOURCE_DIRECTORY}\" CMake")<br />
<br />
# which ctest command to use for running the dashboard<br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake/bin/ctest.exe -D Nightly"<br />
)<br />
<br />
# what cmake command to use for configuring this dashboard<br />
SET (CTEST_CMAKE_COMMAND <br />
"C:/Program Files/CMake/bin/cmake.exe"<br />
)<br />
<br />
<br />
####################################################################<br />
# The values in this section are optional you can either<br />
# have them or leave them commented out<br />
####################################################################<br />
<br />
# should ctest wipe the binary tree before running<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)<br />
<br />
# this is the initial cache to use for the binary tree, be careful to escape<br />
# any quotes inside of this string if you use it<br />
SET (CTEST_INITIAL_CACHE "<br />
MAKECOMMAND:STRING=nmake -i<br />
CMAKE_MAKE_PROGRAM:FILEPATH=nmake<br />
CMAKE_GENERATOR:INTERNAL=NMake Makefiles<br />
BUILDNAME:STRING=Win32-nmake71<br />
SITE:STRING=VOGON.kitware<br />
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe<br />
")<br />
<br />
# set any extra environment variables to use during the execution of the script here:<br />
SET (CTEST_ENVIRONMENT<br />
)<br />
</pre><br />
<br />
=== ctest using git ===<br />
<br />
<pre><br />
set(CTEST_SOURCE_DIRECTORY "$ENV{HOME}/workspace/tmp/dashboards/libssh/source")<br />
set(CTEST_BINARY_DIRECTORY "$ENV{HOME}/workspace/tmp/dashboards/libssh/build")<br />
<br />
set(CTEST_SITE "host.libssh.org")<br />
set(CTEST_BUILD_NAME "linux-gcc-default")<br />
<br />
set(CTEST_CMAKE_GENERATOR "Unix Makefiles")<br />
set(CTEST_BUILD_CONFIGURATION "Profiling")<br />
set(CTEST_BUILD_OPTIONS "-DWITH_SSH1=ON -WITH_SFTP=ON -DWITH_SERVER=ON -DWITH_ZLIB=ON -DWITH_PCAP=ON -DWITH_GCRYPT=OFF")<br />
<br />
set(WITH_MEMCHECK TRUE)<br />
set(WITH_COVERAGE TRUE)<br />
<br />
#######################################################################<br />
<br />
ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})<br />
<br />
find_program(CTEST_GIT_COMMAND NAMES git)<br />
find_program(CTEST_COVERAGE_COMMAND NAMES gcov)<br />
find_program(CTEST_MEMORYCHECK_COMMAND NAMES valgrind)<br />
<br />
set(CTEST_MEMORYCHECK_SUPPRESSIONS_FILE ${CTEST_SOURCE_DIRECTORY}/tests/valgrind.supp)<br />
<br />
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_GIT_COMMAND} clone git://git.libssh.org/projects/libssh/libssh.git ${CTEST_SOURCE_DIRECTORY}")<br />
endif()<br />
<br />
set(CTEST_UPDATE_COMMAND "${CTEST_GIT_COMMAND}")<br />
<br />
set(CTEST_CONFIGURE_COMMAND "${CMAKE_COMMAND} -DCMAKE_BUILD_TYPE:STRING=${CTEST_BUILD_CONFIGURATION}")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} -DWITH_TESTING:BOOL=ON ${CTEST_BUILD_OPTIONS}")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} \"-G${CTEST_CMAKE_GENERATOR}\"")<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_CONFIGURE_COMMAND} \"${CTEST_SOURCE_DIRECTORY}\"")<br />
<br />
ctest_start("Nightly")<br />
ctest_update()<br />
ctest_configure()<br />
ctest_build()<br />
ctest_test()<br />
if (WITH_COVERAGE AND CTEST_COVERAGE_COMMAND)<br />
ctest_coverage()<br />
endif (WITH_COVERAGE AND CTEST_COVERAGE_COMMAND)<br />
if (WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND)<br />
ctest_memcheck()<br />
endif (WITH_MEMCHECK AND CTEST_MEMORYCHECK_COMMAND)<br />
ctest_submit()<br />
</pre><br />
<br />
To use SVN, just change the ''CVSCOMMAND'' line by ''SVNCOMMAND'' and give the right path to the ''svn.exe'' program. Also, don't forget to change the ''LC_MESSAGES'' environment variable to ''en_US'' in your script or directly in your system. This will force the SVN output language to english so that CTest will be able to analyse the data from SVN and submit them correctly to Dart2.<br />
<br />
<pre><br />
SET( ENV{LC_MESSAGES} "en_US" )<br />
</pre><br />
<br />
If you want also the compiler output to be ASCII only (and cope with CDash integration), simply use:<br />
<br />
<pre><br />
SET( ENV{LANG} "C" )<br />
</pre><br />
<br />
<br />
This script defined all the information CTest needs to submit CMake<br />
dashboard on Windows XP computer using NMake build system. The syntax<br />
used is the same as in CMake. Also, most commands available in CMake are<br />
available here, except things that require generator, such as<br />
TRY_COMPILE, ADD_LIBRARY, etc.<br />
<br />
The script can be run by executing:<br />
<br />
<pre><br />
ctest -S /path/to/script.cmake<br />
</pre><br />
<br />
or in this case:<br />
<br />
<pre><br />
c:/Program Files/CMake/bin/ctest -S c:/Hoffman/DashboardScripts/vogon_cmake_nmake.cmake<br />
</pre><br />
<br />
===Main Settings===<br />
<br />
Every CTest script has to contain the source and binary directory:<br />
<br />
<pre><br />
SET (CTEST_SOURCE_DIRECTORY "$ENV{HOME}/Dashboards/My Testing/Insight")<br />
SET (CTEST_BINARY_DIRECTORY "$ENV{HOME}/Dashboards/My Testing/Insight-bin")<br />
</pre><br />
<br />
The "$ENV{HOME}" gets replaced by the environment variable "HOME", which<br />
on most systems points to user's home directory.<br />
<br />
Second thing we need is the command that perform initial configuration<br />
of the project. For example, if the project uses CMake, then the command<br />
would be something like:<br />
<br />
<pre><br />
SET (CTEST_CMAKE_COMMAND "/usr/local/bin/cmake")<br />
</pre><br />
<br />
That assumes that CMake is installed in /usr/local. Similarly to setting<br />
up CMake command, we need to setup the way CTest will be called. Let say<br />
in your case you run CTest using:<br />
<br />
<pre><br />
ctest -D Nightly<br />
</pre><br />
<br />
Then the command in the CTest script should be:<br />
<br />
<pre><br />
SET (CTEST_COMMAND "/usr/local/bin/ctest -D Nightly")<br />
</pre><br />
<br />
The final important piece we need is the initial cache that CMake uses<br />
to configure the project. This should be minimal set of settings that<br />
will allow the system to test certain aspect of the project. Example<br />
initial cache would be:<br />
<br />
<pre><br />
SET (CTEST_INITIAL_CACHE "<br />
//Name of generator.<br />
CMAKE_GENERATOR:INTERNAL=Visual Studio 7<br />
<br />
//Name of the build<br />
BUILDNAME:STRING=Win32-vs70<br />
<br />
//Name of the computer/site where compile is being run<br />
SITE:STRING=DASH2.kitware<br />
<br />
//Build VTK with shared libraries.<br />
BUILD_SHARED_LIBS:BOOL=ON<br />
<br />
//Path to the CVS<br />
CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe<br />
<br />
//ITK TCL and Python wrapping<br />
ITK_CSWIG_TCL:BOOL=ON<br />
ITK_CSWIG_PYTHON:BOOL=ON<br />
")<br />
</pre><br />
<br />
This will set the generator to be "Visual Studio 7", it will use shared<br />
libraries and turn on TCL and Python wrapping. Also, in the cache we can<br />
set the SITE and BUILDNAME variables, which will be used to display the<br />
testing results on the dashboard.<br />
<br />
If you do not use default generator (such as Unix Makefiles), make sure you specify one. On systems that have multimple generators, it is a good idea to specify one always, since otherwise CMake might pick the wrong one.<br />
<br />
Available generators are:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Generator !! Description<br />
|-<br />
| Unix Makefiles<br />
| Unix style makefiles that can be processed using most Make processors except nonconforming processors such as NMake and Borland Make.<br />
|-<br />
| Borland Makefiles<br />
| Makefiles that can be processed using Borland Make processor<br />
|-<br />
| NMake Makefiles<br />
| Makefiles that can be processed using NMake Make processor<br />
|-<br />
| Visual Studio 6<br />
| Visual studio 6 project files<br />
|-<br />
| Visual Studio 7<br />
| Visual Studio 7 project files (not same as Visual Studio 7 .NET 2003<br />
|-<br />
| Visual Studio 7 .NET 2003<br />
| Visual Studio 7 .NET 2003 project files<br />
|-<br />
| Visual Studio 8 2005<br />
| Visual Studi 8 (aka Visual Studio 2005) project files.<br />
|}<br />
<br />
<br />
This is it. The CTest script can now be tested using:<br />
<br />
<pre><br />
ctest -S /path/to/script/script.cmake -V<br />
</pre><br />
<br />
The -V argument tells CTest to be extra verbose when doing dashboard.<br />
<br />
===More Settings===<br />
<br />
The main settings will generate dashboard for most systems. There are<br />
however issues in certain setups.<br />
<br />
Most dashboard contributors want to start dashboard and not touch those<br />
systems for months. The problem is that the binary directory of the<br />
project will grow larger and larger. Common practice therefore is to<br />
wipe out binary directory every time dashboard is run. We can achieve<br />
this in CTest script by setting:<br />
CTEST_START_WITH_EMPTY_BINARY_DIRECTORY:<br />
<br />
<pre><br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)<br />
</pre><br />
<br />
Now CTest will wipe out the binary tree every time. Make sure that the<br />
source tree is not equal to binary tree.<br />
<br />
Second useful option is setting of environment in which CTest runs. Let<br />
say you have Cygwin, Borland, Visual Studio, and Intel compiler on your<br />
Windows system and you do not want to have system's global PATH pointing<br />
to various directories (Borland and Cygwin use "make", which one should<br />
be used). Now you want to do Borland dashboard. You can set environment<br />
variables using CTEST_ENVIRONMENT:<br />
<br />
<pre><br />
SET (CTEST_ENVIRONMENT<br />
"PATH=c:/WINDOWS/system32\;c:/WINDOWS\;c:/Programs/Borland/Bcc55/Bin")<br />
</pre><br />
<br />
Note that CTEST_ENVIRONMENT can accept multiple environment variables.<br />
For example:<br />
<br />
<pre><br />
SET (CTEST_ENVIRONMENT<br />
"DISPLAY=:0"<br />
"GLIBCPP_FORCE_NEW=1"<br />
"CC=gcc-3.4"<br />
"CXX=g++-3.4"<br />
)<br />
</pre><br />
<br />
Another useful thing to do is to perform extra update on external<br />
repository. For example, VTK dashboard need to update VTK data. This can<br />
be achieved using CTEST_EXTRA_UPDATES_*. This also requires the<br />
CTEST_CVS_COMMAND to be set. An example of extra update is:<br />
<br />
<pre><br />
SET (CTEST_CVS_COMMAND "/usr/bin/cvs")<br />
SET (CTEST_EXTRA_UPDATES_1 "$ENV{HOME}/Dashboards/MyTests/VTKData" "-dAP")<br />
</pre><br />
<br />
There can be up to ten CTEST_EXTRA_UPDATES_* settings:<br />
CTEST_EXTRA_UPDATES_1, CTEST_EXTRA_UPDATES_2, ...,<br />
CTEST_EXTRA_UPDATES_10.<br />
<br />
Extra update can also be used to update DartConfig.cmake to the latest version, to receive settings right away instead of waiting until next day. An example of those kind of settings is a nightly start time.<br />
<br />
<pre><br />
SET (CTEST_EXTRA_UPDATES_2 "${CTEST_SOURCE_DIRECTORY}" " -dAP DartConfig.cmake")<br />
</pre><br />
<br />
===Advanced Settings===<br />
<br />
When performing complex dashboards setups, some more CMake/CTest<br />
knowledge is needed. This section will describe solutions to some common<br />
CTest problems.<br />
<br />
====Memory Checking====<br />
<br />
Doing memory checking using Valgrind or similar product can take<br />
significant amount of time. There are two improvements the dashboard<br />
contributor can do to make dashboard more useful. First one is to submit<br />
partial results. This can be achieved by breaking down the CTest run<br />
into individual runs:<br />
<br />
<pre><br />
SET (CTEST_COMMAND <br />
"/usr/local/bin/ctest -D NightlyStart -D NightlyUpdate -D NightlyConfigure -D NightlyBuild -D NightlyTest -D NightlySubmit"<br />
"/usr/local/bin/ctest -D NightlyMemCheck -D NightlySubmit"<br />
)<br />
</pre><br />
<br />
The first CTest command will perform standard Nightly dashboard.<br />
The last two will perform only Memory checking and submission. This the<br />
whole dashboard submission will be there except the memory checking.<br />
Once the memory checking is completed, it will be submitted.<br />
<br />
The second thing is to add special flags to make the CTest only test<br />
subset of tests:<br />
<br />
<pre><br />
SET (CTEST_COMMAND<br />
...<br />
"/usr/local/bin/ctest -D NightlyMemCheck -I 0,,17"<br />
"/usr/local/bin/ctest -D NightlySubmit"<br />
)<br />
</pre><br />
<br />
The "-I 0,,17" will tell CTest to only run memory checking of every 17th<br />
test.<br />
<br />
====Initial Checkout====<br />
<br />
Let say you do not want to require the source of the project to be<br />
available. This is useful if the dashboards are performed on the<br />
temporary drive that can get erased. The following setting will checkout<br />
the source tree of CMake out of CVS repository before the testing is<br />
performed:<br />
<br />
<pre><br />
SET (CTEST_CVS_CHECKOUT<br />
"${CTEST_CVS_COMMAND} -q -z3<br />
-d :pserver:anoncvs@www.cmake.org:/cvsroot/CMake<br />
co -d \"CMake\" -D yesterday CMake")<br />
</pre><br />
<br />
Another useful feature is to backup source tree before performing<br />
dashboard. This way if the build fails, you can restore the old tree.<br />
This is useful when you require the source tree to be in good condition.<br />
This option has to be used in combination with CTEST_CVS_CHECKOUT. To<br />
turn this feature on, add this to CTest script:<br />
<br />
<pre><br />
SET (CTEST_BACKUP_AND_RESTORE TRUE) <br />
</pre><br />
<br />
====Continuous Builds (old Style) ====<br />
<br />
When setting up Continuous dashboard, the CTest has to be run<br />
periodically to check if there were any changes in the source. When the<br />
change appears, the full dashboard is tested. This can be achieved by<br />
running CTest from system scheduler or some script, or by using<br />
Continuous feature of CTest script. First of all, make sure that<br />
CTEST_COMMAND is using Continuous model:<br />
<br />
<pre><br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake20/bin/ctest.exe -D Continuous"<br />
)<br />
</pre><br />
<br />
Also, if the number of tests is high, you may want to only run subset of<br />
tests:<br />
<br />
<pre><br />
SET (CTEST_COMMAND <br />
"C:/Program Files/CMake20/bin/ctest.exe -D Continuous -I ,,3"<br />
)<br />
</pre><br />
<br />
Now set the continuous parameters:<br />
<br />
<pre><br />
SET (CTEST_CONTINUOUS_DURATION 600)<br />
SET (CTEST_CONTINUOUS_MINIMUM_INTERVAL 10)<br />
SET (CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE 1)<br />
</pre><br />
<br />
The CTEST_CONTINUOUS_DURATION is the duration of Continuous testing in<br />
minutes. In this case it will run Continuous dashboards for 10 hours. If<br />
it starts at 8 AM, the last continuous will be done around 6 PM. The<br />
CTEST_CONTINUOUS_MINIMUM_INTERVAL is the minimum interval between<br />
Continuous checks. In this case it will perform check every 10 minutes.<br />
CTEST_START_WITH_EMPTY_BINARY_DIRECTORY_ONCE will remove binary tree<br />
once the first Continuous is run. This way Continuous tests will take<br />
less time, since it will only rebuild modified files.<br />
<br />
====Continuous Builds (new Style) ====<br />
<br />
CTEST_CONTINUOUS_DURATION is not used in the new style scripts. Instead, you you should use something like this:<br />
<br />
<pre><br />
while (${CTEST_ELAPSED_TIME} LESS 36000)<br />
set (START_TIME ${CTEST_ELAPSED_TIME})<br />
ctest_start (Continuous)<br />
ctest_update (RETURN_VALUE count)<br />
if (count GREATER 0)<br />
ctest_configure()<br />
....<br />
endif ()<br />
ctest_sleep( ${START_TIME} 300 ${CTEST_ELAPSED_TIME})<br />
endwhile()<br />
</pre><br />
<br />
===Available Variables===<br />
<br />
When running CTest scripts, there are several variables available that<br />
can simplify writing CTest scripts. These variable include:<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Variable !! Description<br />
|-<br />
| CTEST_SCRIPT_DIRECTORY <br />
| Location of directory in which the CTest script is<br />
|-<br />
| CTEST_SCRIPT_NAME<br />
| Name of the CTest script<br />
|- valign="top"<br />
| CTEST_SCRIPT_ARG<br />
| The extra arguments passed to CTest -S. For example, when running:<br />
<br />
<pre><br />
ctest -S /home/scripts/mysystem.cmake,Experimental<br />
</pre><br />
<br />
then the CTEST_SCRIPT_ARG will be set to Experimental. Then this can be<br />
used inside the script:<br />
<br />
<pre><br />
SET(MODEL Nightly)<br />
IF(${CTEST_SCRIPT_ARG} MATCHES Experimental)<br />
SET(MODEL Experimental)<br />
ENDIF(${CTEST_SCRIPT_ARG} MATCHES Experimental)<br />
SET (CTEST_COMMAND<br />
"/usr/local/bin/ctest -D ${MODEL}")<br />
</pre><br />
<br />
Now we can specify Nighlty or Experimental without editing CTest script.<br />
|-<br />
|}<br />
<br />
==Setting Up Cron/Scheduler==<br />
<br />
===On Unix/MacOSX===<br />
<br />
Most Unix and Unix like systems use '''cron'''. Cron is a daemon that runs programs at specified times as described in crontab. Example of crontab is:<br />
<br />
<pre><br />
1 22 * * * /usr/bin/ctest -S /dash/dash1.cmake -V > /dash/logs/tests.log 2>&1<br />
</pre><br />
<br />
The part of the line:<br />
<pre><br />
1 22 * * *<br />
</pre><br />
<br />
specifies when to run the scheduled task. The columns correspond to minutes, hours, days, months, day of the week. This gets translated to 10:01 PM every day, every month.<br />
Another example would be:<br />
<br />
<pre><br />
47 6 * * 7<br />
</pre><br />
<br />
which is 6:47 AM on sunday.<br />
<br />
The end of the line:<br />
<br />
<pre><br />
> /dash/logs/tests.log 2>&1<br />
</pre><br />
<br />
is korn-shell (/bin/sh) syntax for sending all messages (standard output and standard error) to a file '''/dash/logs/tests.log'''. If you set different shell in your crontab, make sure to use apropriate syntax.<br />
<br />
To enable crontab, use the following command:<br />
<br />
<pre><br />
crontab -e<br />
</pre><br />
<br />
===On Windows / Cygwin / MinGW===<br />
<br />
The following images are generated on Windows XP Pro, but the concepts should be the same on all Windows systems. Make sure to enable password for the user, otherwise scheduled tasks will not work.<br />
<br />
1. Open "Scheduled Tasks" from Control Panel.<br />
<br />
[[Image:Sc_task_scheduler.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
2. Select '''Add Scheduled Task'''<br />
<br />
[[Image:Sc_start_new_scheduled_task.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
3. Select '''Next''' to select command.<br />
<br />
[[Image:Sc_select_browse.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
4. Click '''Browse...''' and select '''CTest.exe'''.<br />
<br />
[[Image:Sc_specify_command.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
5. Click '''Next''' and select name and repetition date. Repetition date for Nightly dashboards should be '''Daily'''.<br />
<br />
[[Image:Sc_specified_name_and_repetition.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
6. Click '''Next''' and select time to start the dashboard.<br />
<br />
[[Image:Sc_set_time.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
7. Click '''Next''' and select '''Open advanced properties...''' to fine tune the scheduled task.<br />
<br />
[[Image:Sc_open_advanced_settings.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
8. Select '''Next''' and type password of the user.<br />
<br />
[[Image:Sc_type_password.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
<br />
9. Task is created. The ''Advanced Properties'' dialog should open.<br />
<br />
[[Image:Sc_task_created.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
10. In advanced properties, specify full command name. This is very important that you use double quotes in case you have space in your path.<br />
<br />
<pre><br />
"c:/Path to ctest/ctest.exe" -S c:/Path to Dashboard Scripts/dashboard_script.cmake -V<br />
</pre><br />
<br />
[[Image:Sc_proper_command_line.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
<br />
11. Select '''Ok'', which will ask for password again.<br />
<br />
[[Image:Sc_finish_password.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
12. The new task should be created.<br />
<br />
[[Image:Sc_new_task_exists.png|left|Task Scheduler]]<br />
<br clear="all"><br />
<br />
==Conclusion==<br />
<br />
CTest scripts can significantly simplify dashboard contribution. Using<br />
simple template script with slight modification, the whole cluster of<br />
various systems can submit dashboards.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CTest:Using_CTEST_and_CDASH_without_CMAKE&diff=62654CTest:Using CTEST and CDASH without CMAKE2018-04-27T14:15:58Z<p>Brad.king: </p>
<hr />
<div>This is a short tutorial, which shows how to use CTest scripts to populate a CDash dashboard. It shows how to checkout, configure, compile and test a project with CTest when not using CMake.<br />
<br />
As this tutorial is the outcome of a test setup, put together form many different sources, it will and can not be complete. It will only give an '''good''' overview. Detailed information can be found on the linked wiki pages or the CTest manual ( <span style="font-family:monospace;font-weight:bold;">$ man ctest</span> ).<br />
<br />
== Pre-requirements for the example setup ==<br />
* Project is under subversion control<br />
* No CTest files shall be stored in the project repository<br />
* Use of the autotools build system<br />
<br />
== Setup files ==<br />
A set of file is needed to form a complete system.<br />
<br />
* [[#steer.cmake|steer.cmake]]<br />
* [[#CTestConfig.cmake|CTestConfig.cmake]]<br />
* [[#CTestCustom.cmake|CTestCustom.cmake]]<br />
* [[#CTestTestfile.cmake|CTestTestfile.cmake]]<br />
<br />
== steer.cmake ==<br />
The steering script. It can be evoked from the command-line or via scheduled tasks for automatic running.<br />
<br />
=== Execute script ===<br />
<pre><br />
$ ctest -S steer.cmake<br />
</pre><br />
<br />
* use <span style="font-family:monospace;font-weight:bold;">-VV</span> for extra verbosity during debugging <br />
* see also [[CMake_Scripting_Of_CTest#Advanced_Settings|here]] for the usage of command line arguments.<br />
<br />
=== Example ===<br />
<br />
The example below intends to be a realistic usecase showing non-trivial usage. All code in this paragraph should be in one file. It is "broken up" only for the purpose of explanation.<br />
<br />
==== The first step is the retrieval of the build environment ====<br />
<br />
'''Get the hostname of current machine'''<br />
<pre><br />
find_program(HOSTNAME_CMD NAMES hostname)<br />
exec_program(${HOSTNAME_CMD} ARGS OUTPUT_VARIABLE HOSTNAME)<br />
set(CTEST_SITE "${HOSTNAME}")<br />
</pre><br />
Finds the paths to the program hostname, executes it, stores the result in ${HOSTNAME}. Then the ''CTEST_SITE'' variable is set, to be used in CDash.<br />
<br />
'''Get the system information of current machine'''<br />
<pre><br />
find_program(UNAME NAMES uname)<br />
macro(getuname name flag)<br />
exec_program("${UNAME}" ARGS "${flag}" OUTPUT_VARIABLE "${name}")<br />
endmacro(getuname)<br />
</pre><br />
Defines the macro getuname, for easy usage of ''uname''<br />
<br />
<pre><br />
getuname(osname -s)<br />
getuname(osrel -r)<br />
getuname(cpu -m)<br />
set(CTEST_BUILD_NAME "${osname}-${cpu}-prod")<br />
</pre><br />
Sets the build name, to be used in CDash.<br />
<br />
'''Get necessary executables'''<br />
<br />
The CTest command for svn (subversion) is found and set here:<br />
<pre><br />
find_program(CTEST_SVN_COMMAND NAMES svn)<br />
</pre><br />
<br />
This finds and sets the full path to the executable for make here:<br />
<pre><br />
find_program(MAKE NAMES make)<br />
</pre><br />
<br />
==== The build specific environment for the project ====<br />
<br />
<pre><br />
set(MODEL analysis)<br />
</pre><br />
Choose the dashboard group to be filled with this script. Not only the standard build groups (Experimental, Continous, Nighlty) can be chosen, but also [[CDash:Administration#Build_Groups|build groups]] which can be defined in CDash.<br />
<br />
<pre><br />
set(CTEST_DASHBOARD_ROOT "$ENV{HOME}/automatedBuild")<br />
set(CTEST_SOURCE_DIRECTORY "${CTEST_DASHBOARD_ROOT}/src")<br />
set(CTEST_BINARY_DIRECTORY "${CTEST_SOURCE_DIRECTORY}/build-${CTEST_BUILD_NAME}")<br />
</pre><br />
Set the source and binary directories of your project.<br />
<br />
==== Commands for the execution of CTest ====<br />
<br />
For an initial checkout, the ''CTEST_CHECKOUT_COMMAND'' has to be set:<br />
<pre><br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_SVN_COMMAND} co http://myRepositoryServer.com/myRepository/trunk ${CTEST_SOURCE_DIRECTORY}")<br />
</pre><br />
<br />
The initial checkout is only done if you specify the update command <span style="font-family:monospace;font-weight:bold;">ctest_update(SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE res)</span> ( see further down), which needs also to be configured :<br />
<pre><br />
set(CTEST_UPDATE_COMMAND "${CTEST_SVN_COMMAND}")<br />
</pre><br />
<br />
If one wants to have a clean checkout every time, then the update column of the dashboard will always say 0. Because it was all checked out in the initial checkout and not in the update. However, if one uses the svn flag <span style="font-family:monospace;font-weight:bold;">-r</span> with ''yesterdays'' date for the initial checkout, the update columns will show the updates which have been done in the last day.<br />
<br />
The commands which are executed in ''ctest_configure'' and ''ctest build'' have to be specified. Both are executed in the binary directory.<br />
<pre><br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_SOURCE_DIRECTORY}/configure --enable-optimization=3 --disable-debug --enable-doc=mono")<br />
set(CTEST_BUILD_COMMAND "/usr/bin/make -j16")<br />
</pre><br />
<br />
==== Configure CTest ====<br />
If the CTest configuration files [[#CTestConfig.cmake|CTestConfig.cmake]], [[#CTestCustom.cmake|CTestCustom.cmake]] and [[#CTestTestfile.cmake|CTestTestfile.cmake]] should or can not be stored in the repository itself, then they can be copied there automatically by CTest.<br />
<br />
<pre><br />
configure_file($ENV{HOME}/CTestConfiguartion/CTestConfig.cmake ${CTEST_SOURCE_DIRECTORY}/CTestConfig.cmake)<br />
configure_file($ENV{HOME}/CTestConfiguartion/CTestCustom.cmake ${CTEST_BINARY_DIRECTORY}/CTestCustom.cmake)<br />
configure_file($ENV{HOME}/CTestConfiguartion/CTestTestfile.cmake ${CTEST_BINARY_DIRECTORY}/CTestTestfile.cmake)<br />
</pre><br />
* ''CTestConfig.cmake'' should be put in the source directory<br />
* ''CTestCustom.cmake'' and ''CTestTestfile.cmake'' should be put in the binary directory<br />
* Full paths should be given<br />
<br />
Then the custom configuration has to be read in.<br />
<pre><br />
ctest_read_custom_files("${CTEST_BINARY_DIRECTORY}")<br />
</pre><br />
<br />
==== General CTest settings ====<br />
<br />
<pre><br />
set(CTEST_TIMEOUT "7200")<br />
</pre><br />
Sets the timeout value for this script in seconds. Here 120 min.<br />
<br />
<pre><br />
set( $ENV{LC_MESSAGES} "en_EN" )<br />
</pre><br />
Set the output language to english, so that CTest can analyze it.<br />
<br />
==== Run CTest ====<br />
<br />
'''Start'''<br />
<br />
<pre><br />
ctest_start(${MODEL} TRACK ${MODEL} )<br />
</pre><br />
Starts CTest and assigns the build track to be filled. It creates automatically the binary directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}</span>, if not present. Furthermore also the directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}/Testing</span> is created, where all the result and log files are stored.<br />
<br />
'''Update / Initial checkout'''<br />
<br />
<pre><br />
ctest_update( SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Performs the update from the repository. As the <span style="font-family:monospace;font-weight:bold;">CTEST_CHECKOUT_COMMAND</span> is set here, also the initial checkout done.<br />
<br />
'''Configure build system'''<br />
<br />
The ''autoreconf'' command of the autotools package is not supported by standard CTest, so the process has to be called manually.<br />
<pre><br />
execute_process(COMMAND "/usr/bin/autoreconf" "-f" "-i" WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY} RESULT_VARIABLE autoreconfResult<br />
OUTPUT_VARIABLE autoreconfLog ERROR_VARIABLE autoreconfLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/autoreconf.log "${autoreconfLog}")<br />
</pre><br />
Runs the ''autoreconf'' command stores both stdout and stderr in a log file.<br />
<br />
In order to execute the configure/build block only if ''autoreconf'' succeeded, they can be put into an if statement<br />
<pre><br />
if( NOT ${autoreconfResult} )<br />
... the other build commands ...<br />
endif( NOT ${autoreconfResult} )<br />
</pre><br />
<br />
'''Configure / Build block'''<br />
<br />
<pre><br />
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Configures the project. It is executed in the binary directory.<br />
<br />
<pre><br />
ctest_build( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Builds the project. It is executed in the binary directory.<br />
<br />
<pre><br />
execute_process(COMMAND "/usr/bin/make install -j 16" "-f" "-i" WORKING_DIRECTORY ${CTEST_BINARY_DIRECTORY} <br />
RESULT_VARIABLE makeInstallResult OUTPUT_VARIABLE makeInstallLog ERROR_VARIABLE makeInstallLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/makeinstall.log "${makeInstallLog}")<br />
</pre><br />
Like the ''autoreconf'' command, the install command is not part of the standard test. It has to be invoked manually.<br />
Both stdout and stderr are written into a log file.<br />
<br />
'''Launch tests'''<br />
<br />
<pre><br />
ctest_test( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Invokes all tests, defined in [[#CTestTestfile.cmake|CTestTestfile.cmake]]<br />
<br />
==== Finialize the submission ====<br />
After the all build steps, the results have to be submitted to CDash via<br />
<pre><br />
ctest_submit( RETURN_VALUE res)<br />
</pre><br />
This uses the settings of [[#CTestConfig.cmake|CTestConfig.cmake]].<br />
<br />
==== Complete Example ====<br />
The complete example '''steer.cmake''' could look like this :<br />
<br />
<pre><br />
# ----------------------------------------------------------- <br />
# -- Get environment<br />
# ----------------------------------------------------------- <br />
<br />
## -- Set hostname<br />
## --------------------------<br />
find_program(HOSTNAME_CMD NAMES hostname)<br />
exec_program(${HOSTNAME_CMD} ARGS OUTPUT_VARIABLE HOSTNAME)<br />
<br />
set(CTEST_SITE "${HOSTNAME}")<br />
<br />
## -- Set site / build name<br />
## --------------------------<br />
<br />
find_program(UNAME NAMES uname)<br />
macro(getuname name flag)<br />
exec_program("${UNAME}" ARGS "${flag}" OUTPUT_VARIABLE "${name}")<br />
endmacro(getuname)<br />
<br />
getuname(osname -s)<br />
getuname(osrel -r)<br />
getuname(cpu -m)<br />
<br />
set(CTEST_BUILD_NAME "${osname}-${cpu}-prod")<br />
<br />
## -- SVN command<br />
## ----------------<br />
find_program(CTEST_SVN_COMMAND NAMES svn)<br />
<br />
## -- make command<br />
## -----------------<br />
find_program(MAKE NAMES make)<br />
<br />
# ----------------------------------------------------------- <br />
# -- build specific<br />
# ----------------------------------------------------------- <br />
<br />
set(MODEL "analysis")<br />
<br />
## -- DashBoard Root<br />
set(CTEST_DASHBOARD_ROOT "$ENV{HOME}/automatedBuild")<br />
<br />
## -- SRC Dir<br />
set(CTEST_SOURCE_DIRECTORY "${CTEST_DASHBOARD_ROOT}/src")<br />
<br />
## -- BIN Dir <br />
set(CTEST_BINARY_DIRECTORY "${CTEST_SOURCE_DIRECTORY}/build-${CTEST_BUILD_NAME}")<br />
<br />
## -- Build options<br />
set(OPTION_BUILD "-j16")<br />
<br />
# ----------------------------------------------------------- <br />
# -- commands<br />
# ----------------------------------------------------------- <br />
<br />
## -- Checkout command<br />
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_SVN_COMMAND} co http://myRepositoryServer.com/myRepository/trunk ${CTEST_SOURCE_DIRECTORY}")<br />
endif(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
<br />
## -- Update Command<br />
set(CTEST_UPDATE_COMMAND "${CTEST_SVN_COMMAND}")<br />
<br />
## -- Configure Command<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_SOURCE_DIRECTORY}/configure configure --enable-optimization=3 --disable-debug --enable-doc=mono")<br />
<br />
## -- Build Command<br />
set(CTEST_BUILD_COMMAND "${MAKE} ${OPTION_BUILD}")<br />
<br />
# ----------------------------------------------------------- <br />
# -- Configure CTest<br />
# ----------------------------------------------------------- <br />
<br />
## -- CTest Config<br />
configure_file($ENV{HOME}/CTestConfiguration/CTestConfig.cmake ${CTEST_SOURCE_DIRECTORY}/CTestConfig.cmake)<br />
<br />
## -- CTest Custom<br />
configure_file($ENV{HOME}/CTestConfiguration/CTestCustom.cmake ${CTEST_BINARY_DIRECTORY}/CTestCustom.cmake)<br />
<br />
## -- CTest Testfile<br />
configure_file($ENV{HOME}/CTestConfiguration/CTestTestfile.cmake ${CTEST_BINARY_DIRECTORY}/CTestTestfile.cmake)<br />
<br />
## -- read CTestCustom.cmake file<br />
ctest_read_custom_files("${CTEST_BINARY_DIRECTORY}")<br />
<br />
# ----------------------------------------------------------- <br />
# -- Settings<br />
# ----------------------------------------------------------- <br />
<br />
## -- Process timeout in seconds<br />
set(CTEST_TIMEOUT "7200")<br />
<br />
## -- Set output to english<br />
set( $ENV{LC_MESSAGES} "en_EN" )<br />
<br />
# ----------------------------------------------------------- <br />
# -- Run CTest<br />
# ----------------------------------------------------------- <br />
<br />
## -- Start<br />
message(" -- Start dashboard ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_start(${MODEL} TRACK ${MODEL})<br />
<br />
## -- Update<br />
message(" -- Update ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_update( SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE res)<br />
<br />
## -- Run autoreconf<br />
message(" -- Autoreconf ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
execute_process(COMMAND "/usr/bin/autoreconf" "-f" "-i" WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY} RESULT_VARIABLE autoreconfResult<br />
OUTPUT_VARIABLE autoreconfLog ERROR_VARIABLE autoreconfLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/autoreconf.log "${autoreconfLog}")<br />
<br />
if( NOT ${autoreconfResult} )<br />
<br />
## -- Configure <br />
message(" -- Configure ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
<br />
## -- BUILD<br />
message(" -- Build ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_build( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
<br />
## -- INSTALL<br />
message(" -- Install ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
execute_process(COMMAND "${MAKE} install ${OPTION_BUILD}" WORKING_DIRECTORY ${CTEST_BINARY_DIRECTORY} <br />
RESULT_VARIABLE makeInstallResult OUTPUT_VARIABLE makeInstallLog ERROR_VARIABLE makeInstallLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/makeinstall.log "${makeInstallLog}")<br />
<br />
## -- TEST<br />
message(" -- Test ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_test( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
<br />
endif( NOT ${autoreconfResult} )<br />
<br />
## -- SUBMIT<br />
message(" -- Submit ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_submit( RETURN_VALUE res)<br />
<br />
message(" -- Finished ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
</pre><br />
<br />
== CTestConfig.cmake ==<br />
This file sets the tranfer parameters that CTest will use when submitting to CDash.<br />
<pre><br />
ctest_submit( RETURN_VALUE res)<br />
</pre><br />
<br />
Several different ways exist to submit results to the dashboard like ''http'', ''ftp'', ''scp'' and ''XML-RPC''. However only the ''http'' case shall be discussed here.<br />
Details can be found an the [[CTest:Submission_Issues||CTest Submission Issues]] page.<br />
<br />
=== Example ===<br />
This file can be also downloaded from CDash after creating a new project.<br />
<br />
<pre><br />
set(CTEST_PROJECT_NAME "Test-Project")<br />
set(CTEST_NIGHTLY_START_TIME "01:00:00 CET")<br />
set(CTEST_DROP_METHOD "http")<br />
set(CTEST_DROP_SITE "myTestNode.myNetwork.com")<br />
set(CTEST_DROP_LOCATION "/cdash/submit.php?project=TestProject")<br />
set(CTEST_DROP_SITE_CDASH TRUE)<br />
</pre><br />
<br />
== CTestCustom.cmake ==<br />
This file is used to customize CTest. A detailed description of all options, can be found [[CMake/Testing_With_CTest#Customizing_CTest|here]]. <br />
In order to be read in properly this file has to be placed in the binary directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}</span>. <br />
<br />
It can also be read from any other location by specifying<br />
<pre><br />
ctest_read_custom_files("<PATH TO CTestCustom.cmake FILE>")<br />
</pre><br />
<br />
=== Examples ===<br />
This are only some examples of customization. The full list and detailed description can be found [[CMake/Testing_With_CTest#Customizing_CTest|here]].<br />
<br />
* Change the maximum numbers of warnings<br />
<pre><br />
set(CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS "500" )<br />
</pre><br />
<br />
* Change the maximum numbers of errors<br />
<pre><br />
set(CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS "200" )<br />
</pre><br />
<br />
* Add ''fake warnings'' to a list of exceptions<br />
<pre><br />
set(CTEST_CUSTOM_WARNING_EXCEPTION<br />
${CTEST_CUSTOM_WARNING_EXCEPTION}<br />
<br />
# -- doxygen warnings<br />
"are not documented:"<br />
"Skipping documentation"<br />
)<br />
</pre><br />
Every regular expression can be added as exception.<br />
<br />
== CTestTestfile.cmake ==<br />
This file specifies the test which should be executed in<br />
<pre><br />
ctest_test( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
<br />
The file should be placed in the binary directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}</span>.<br />
<br />
=== Examples ===<br />
Each test consists of:<br />
* The unique name of the test ( eg.: <span style="font-family:monospace;font-weight:bold;">testname1</span> )<br />
* The full path to the executable of the test ( eg.: <span style="font-family:monospace;font-weight:bold;">"$ENV{HOME}/bin/TEST_EXECUTABLE_1.sh"</span> )<br />
* A List of arguments to the executable ( eg.: <span style="font-family:monospace;font-weight:bold;">"ARGUMENT_1"</span> <span style="font-family:monospace;font-weight:bold;">"ARGUMENT_2"</span> etc. )<br />
<br />
<pre><br />
ADD_TEST(testname1 "$ENV{HOME}/bin/TEST_EXECUTABLE_1.sh" "ARGUMENT_1")<br />
ADD_TEST(testname2 "$ENV{HOME}/bin/TEST_EXECUTABLE_2.sh")<br />
</pre><br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=Symbian_Carbide_Generator&diff=62653Symbian Carbide Generator2018-04-27T14:12:04Z<p>Brad.king: </p>
<hr />
<div>=Overview=<br />
<br />
Work on a Symbian Carbide.c++ generator is in progress. You can read more about the progress on [http://public.kitware.com/Bug/view.php?id=8486 this] bug report.<br />
<br />
Carbide is the common IDE for Symbian development, the output of this generator can be compiled using the Carbide IDE or from command line.<br />
<br />
This generator creates a set of .bld.inf/.mpp/.mk files that can be imported in Carbide as an "Symbian OS Bld.inf file".<br />
<br />
A bld.inf file in Carbide is similar to a solution (.sln) file in visual studio, it contains a list project paths, the order of the projects is the order that they are going to be built.<br />
<br />
An .mmp file in Carbide is similar to a project(.vcproj) file in visual studio, it contains source file paths, include paths, macro definitions and all sort of other definitions that defines a c\c++ compiler\linker output (exe, dll, lib and such). <br />
<br />
CMake rules are implemented using make files (.mk) project that are before each project .mmp file in the bld.inf file. <br />
<br />
=Using Symbian Carbide.c++ Generator=<br />
<br />
==System requirements for Carbide.c++==<br />
* A windows OS (XP, Vista, Win7)<br />
* About 4GB of space on drive C:<br />
* Fast internet bandwidth - the downloads needed are about 1GB.<br />
* An hour of free time.<br />
<br />
==Creating a Carbide.c++ development environment==<br />
<br />
Follow the following steps.<br />
<br />
===Open up an account on Symbian developer community===<br />
This is needed so you can download files from the Symbian site.<br />
You can register on [https://developer.symbian.org/main/user_profile/register.php this] page, make sure you give out a valid e-mail address, if you don't want to give out your real address - you can use [http://www.mytrashmail.com this] site to get a temporary e-mail for the e-mail activation step in the registration.<br />
<br />
===Download and install Carbide===<br />
* Go to [http://developer.symbian.org/main/tools_and_kits/downloads/view.php?id=2 this] page.<br />
* Download "ADT" (The link is on the right site of the page).<br />
* Make sure that no other version of ADT\Carbide is installed on your system - remove the old install if needed.<br />
* Install the file you downloaded.<br />
<br />
===Download and install the S60 Nokia Symbian SDK===<br />
* Go to [http://developer.symbian.org/main/tools_and_kits/downloads/view.php?id=3 this] page.<br />
* Download "SDK - (from Nokia)" (The link is on the right site of the page).<br />
* Make sure that no other version of this type of Nokia SDK is installed on your system - remove the old install if needed.<br />
* Install the file you downloaded.<br />
* you must configure the environment for use with the S60 emulator. This is done by locating the Carbide.C++ submenu on the Start menu, and choosing "Configure environment for WINSCW command line". <br />
<br />
==Create a Carbide project using the generator==<br />
You must have a Symbian development environment ready on your computer as described on this wiki page above.<br />
<br />
You also must have a version of CMake that includes this generator.<br />
<br />
Generating the project is the same as for any other generator target of CMake, the name of the generator is "Carbide".<br />
<br />
Note however the following limitations (forced by this development environment):<br />
* All of the project source files and dependencies must be on drive C:<br />
* You can't have spaces in folder names.<br />
* CXX extension is treated as C and not CPP by the compiler (the generator solves this by creating a new CPP file with a single #include to the original file and adding it instead to the project).<br />
* Source files with the same name but in different folders are not supported (the generator solves this by creating a new source file with a unique name and a single #include to the original file)<br />
* DLL exports need to be declared per data member in both declaration and implementation. Read more about how to export from a DLL [http://www.newlc.com/en/Writing-a-DLL.html here].<br />
* There is an option to create command line application that will run on the Symbian emulation, and even get the result code from them, but you can't capture the console output as you would from a normal command line application.<br />
* The working directory of an exe is not the path of exe but a different folder on the device\emulation.<br />
<br />
==Importing a project to the Carbide IDE==<br />
[[File:Carbide-import1.jpg|100px|thumb|Figure 1]]<br />
[[File:Carbide-import2.jpg|100px|thumb|Figure 2]]<br />
As the Figure shows, by selecting '''File > Import''' menu item, the developer launches an import panel which has various options, amongst which is the option to import a bld.inf file as shown in figure 1. After selecting this option, the developer is asked to select the bld.inf file to import from the host computer's hard dis(s).<br />
<br />
When this step is completed, Carbide.c++ displays all the Symbian Platform SDKs that are installed on the host PC (known as autodetection) and asks the developer to select the one appropriate for the project, as shown in figure 2. In the next step, the developer can select which of the Symbian MMP files referenced in the imported bld.inf file should be used in order to parse the appropriate MMP file(s). Finally, the developer can select the project name and the root directory for the project. At the end of this wizard's operation, a Symbian C++ project is opened and ready for development in Carbide.c++.<br />
<br />
[[File:Carbide-import3.jpg|100px|thumb|right|Figure 3]]<br />
[[File:Carbide-import4.jpg|100px|thumb|right|Figure 4]]<br />
<br />
=Known open issues with this generator=<br />
* Only DLL, EXE and LIB targets are supported for now.<br />
* There is no support for mmp "[http://developer.symbian.org/main/documentation/reference/s%5E3/doc_source/ToolsAndUtilities96/Build-ref/Mmp-ref/bitmap.html Bitmap]" yet.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAddUninstallTarget&diff=62652RecipeAddUninstallTarget2018-04-26T16:32:01Z<p>Brad.king: </p>
<hr />
<div>This is a slight hack for adding an uninstall target. It parses the install manifest and removes all of those same files. If your program generates files at runtime, this uninstaller won't even know they exist and will leave them. There are a few assumptions made here, such as that your project has a folder called "cmake" that contains the cmake_uninstall.cmake file. Credit is due to the original author but I've had this one for so long, I can't remember the origins.<br />
<br />
Add this to your top-level CMakeLists.txt:<br />
<br />
<pre><br />
########### Add uninstall target ###############<br />
CONFIGURE_FILE(<br />
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/cmake_uninstall.cmake.in"<br />
"${CMAKE_CURRENT_BINARY_DIR}/cmake/cmake_uninstall.cmake"<br />
IMMEDIATE @ONLY)<br />
ADD_CUSTOM_TARGET(uninstall<br />
"${CMAKE_COMMAND}" -P "${CMAKE_CURRENT_BINARY_DIR}/cmake/cmake_uninstall.cmake") <br />
</pre><br />
<br />
Create this file as cmake_uninstall.cmake into your project's "cmake" folder:<br />
<br />
<pre><br />
IF(NOT EXISTS "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt")<br />
MESSAGE(FATAL_ERROR "Cannot find install manifest: "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt"")<br />
ENDIF(NOT EXISTS "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt")<br />
<br />
FILE(READ "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt" files)<br />
STRING(REGEX REPLACE " " ";" files "${files}")<br />
FOREACH(file ${files})<br />
MESSAGE(STATUS "Uninstalling "$ENV{DESTDIR}${file}"")<br />
IF(EXISTS "$ENV{DESTDIR}${file}")<br />
EXEC_PROGRAM(<br />
"@CMAKE_COMMAND@" ARGS "-E remove "$ENV{DESTDIR}${file}""<br />
OUTPUT_VARIABLE rm_out<br />
RETURN_VALUE rm_retval<br />
)<br />
IF(NOT "${rm_retval}" STREQUAL 0)<br />
MESSAGE(FATAL_ERROR "Problem when removing "$ENV{DESTDIR}${file}"")<br />
ENDIF(NOT "${rm_retval}" STREQUAL 0)<br />
ELSE(EXISTS "$ENV{DESTDIR}${file}")<br />
MESSAGE(STATUS "File "$ENV{DESTDIR}${file}" does not exist.")<br />
ENDIF(EXISTS "$ENV{DESTDIR}${file}")<br />
ENDFOREACH(file)<br />
</pre><br />
<br />
Now, you should be able to run "make install" to install your project and then "make uninstall" to remove the files. <br />
<br />
Credit to the CMake mailing list archives for providing this solution.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAppendVersionNumberToInstallpath&diff=62651RecipeAppendVersionNumberToInstallpath2018-04-26T16:31:33Z<p>Brad.king: </p>
<hr />
<div>In some situations, it's necessary to keep older versions of a program along with the newer. Here is a recipe for appending the version number to your install path:<br />
<br />
<pre><br />
IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)<br />
SET(ORIGINAL_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX} CACHE STRING "Default prefix path" FORCE)<br />
ENDIF()<br />
MARK_AS_ADVANCED(ORIGINAL_INSTALL_PREFIX)<br />
<br />
IF( NOT( VERSION VERSION_EQUAL PROJECT_VERSION) )<br />
SET(CMAKE_INSTALL_PREFIX "${ORIGINAL_INSTALL_PREFIX}-${VERSION}" CACHE STRING "Install path" FORCE)<br />
SET(PROJECT_VERSION ${VERSION})<br />
ENDIF()<br />
</pre><br />
<br />
This ensures that the CMAKE_INSTALL_PREFIX is updated whenever the old version number and the new version number doesn't match. This does have some side-effects, such as situations where the user is customizing the CMAKE_INSTALL_PREFIX to some custom location. Such users would need to modify the ORIGINAL_INSTALL_PREFIX instead to ensure that the project is going to the desired place. <br />
<br />
The CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is necessary here because if it's missing, the path becomes recursive and will continue to append ${PROJECT_NAME}-${VERSION} to the path infinitely. The conditional ensures that it only does this once.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAddSoVersionToDLLs&diff=62650RecipeAddSoVersionToDLLs2018-04-26T16:30:50Z<p>Brad.king: </p>
<hr />
<div>When building for platforms that don't allow .so versioning, it's sometimes nice to be able to see at a glance what version of the API the .so library supports. Here's some example code for adding this to non-linux platforms and not breaking linux platforms in the process:<br />
<br />
<pre><br />
SET( GENERIC_DLL_VERSION ${VERSION} )<br />
SET( MYDLL_SOVERSION 1 )<br />
...<br />
ADD_LIBRARY(mydll SHARED ${mydll_SRCS})<br />
target_link_libraries(mydll otherlib)<br />
IF( WIN32 )<br />
SET_TARGET_PROPERTIES( mydll PROPERTIES<br />
OUTPUT_NAME "mydll-${MYDLL_SOVERSION}"<br />
VERSION ${GENERIC_DLL_VERSION} )<br />
ELSE()<br />
SET_TARGET_PROPERTIES( mydll PROPERTIES<br />
VERSION ${GENERIC_DLL_VERSION}<br />
SOVERSION ${MYDLL_SOVERSION} )<br />
ENDIF()<br />
</pre><br />
<br />
You will need to be sure to increment the VERSION and MYDLL_SOVERSION every time the program or the SOVERSION changes (respectively). <br />
<br />
One thing I'd like to try in the future is add something to my unit tests that grep the source headers for the API and complain when it's changed to remind me to update the SOVERSION.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=VSConfigSpecificSettings&diff=62649VSConfigSpecificSettings2018-04-26T16:26:14Z<p>Brad.king: </p>
<hr />
<div>This was taken from a thread on the CMake users mailing list found here:<br />
<br />
[http://www.cmake.org/pipermail/cmake/2008-October/024468.html Mail Thread]<br />
<br />
Basically the following is needed in your cmakelists.txt file.<br />
<br />
<pre><br />
if(WIN32)<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_DEBUG "/SUBSYSTEM:CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES COMPILE_DEFINITIONS_DEBUG "_CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELWITHDEBINFO "/SUBSYSTEM:CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES COMPILE_DEFINITIONS_RELWITHDEBINFO "_CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELEASE "/SUBSYSTEM:WINDOWS")<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_MINSIZEREL "/SUBSYSTEM:WINDOWS")<br />
endif(WIN32)<br />
</pre><br />
<br />
This will cause debug builds to use the console and release builds to NOT show a console.<br />
<br />
Search Engine: Visual Studio 2005 2008 console show hide debug release how to configuration<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=VSConfigSpecificSettings&diff=62648VSConfigSpecificSettings2018-04-26T16:25:49Z<p>Brad.king: </p>
<hr />
<div>This was taken from a thread on the CMake users mailing list found here:<br />
<br />
[http://www.cmake.org/pipermail/cmake/2008-October/024468.html Mail Thread]<br />
<br />
Basically the following is needed in your cmakelists.txt file.<br />
<br />
if(WIN32)<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_DEBUG "/SUBSYSTEM:CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES COMPILE_DEFINITIONS_DEBUG "_CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELWITHDEBINFO "/SUBSYSTEM:CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES COMPILE_DEFINITIONS_RELWITHDEBINFO "_CONSOLE")<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_RELEASE "/SUBSYSTEM:WINDOWS")<br />
set_target_properties(WindowApplicationExample PROPERTIES LINK_FLAGS_MINSIZEREL "/SUBSYSTEM:WINDOWS")<br />
endif(WIN32)<br />
<br />
This will cause debug builds to use the console and release builds to NOT show a console.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Search Engine: Visual Studio 2005 2008 console show hide debug release how to configuration<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=PC-Lint&diff=62647PC-Lint2018-04-26T16:23:27Z<p>Brad.king: </p>
<hr />
<div>= CMake script for generating PC-Lint targets =<br />
<br />
''add_pc_lint'' is a CMake macro for generating build targets for PC-Lint.<br />
<br />
If you use it, you will get a build target invoking pc-lint for each source file with the same include directories and preprocessor defines as for the compiler. The lint build target will have the same name as your original build target, but with ''_LINT'' appended. You will also get the build target ALL_LINT which invokes all *_LINT targets. The *_LINT targets will not be built with ALL_BUILD. Only if they are directly built or if ALL_LINT is built.<br />
<br />
This setup integrates PC-Lint into your existing setup. It has been tested with Visual Studio 8 and NMake Makefiles.<br />
<br />
=== Usage ===<br />
<br />
If you want to use this macro, you need:<br />
<br />
* an existing CMake setup for your project<br />
* PC-Lint installed<br />
* configuration files for PC-Lint<br />
<br />
==== Synopsis ====<br />
<br />
add_pc_lint(target source1 [source2 ...])<br />
<br />
; target : the name of the target to which the sources belong. You will get a new build target named ${target}_LINT<br />
<br />
; source1 source2 ... : a list of source files to be linted. Just pass the same list as you passed for add_executable or add_library. Everything except C and CPP files (*.c, *.cpp, *.cxx) will be filtered out.<br />
<br />
==== Example ====<br />
<br />
If you have a CMakeLists.txt which generates an executable (or library) like this:<br />
<br />
<pre><br />
set(MAIN_SOURCES main.c foo.c bar.c)<br />
add_executable(main ${MAIN_SOURCES})<br />
</pre><br />
<br />
include this file (only once, preferrably at the top level CMakeLists.txt)<br />
<br />
<pre><br />
include(/path/to/pc_lint.cmake)<br />
</pre><br />
<br />
and add a command to generate the main_LINT target<br />
<br />
<pre><br />
if(COMMAND add_pc_lint)<br />
add_pc_lint(main ${MAIN_SOURCES})<br />
endif(COMMAND add_pc_lint)<br />
</pre><br />
<br />
=== Configuration ===<br />
<br />
The pc_lint.cmake script exports the following CMake cache variables, which you have to adjust using the CMake tools to fit your environment.<br />
<br />
; PC_LINT_EXECUTABLE : Full path to the pc-lint executable. Not the generated lin.bat. On a standard PC-Lint installation, this path is ''c:/lint/lint-nt.exe''<br />
<br />
; PC_LINT_CONFIG_DIR : Full path to the directory containing pc-lint configuration files. For each Platform/Compiler/Toolchain, you may want to have a different set of options. If you keep these options in separate directories, you can point this variable to the appropriate one. ''add_pc_lint'' assumes that there is a file called ''std.lnt'' in the configuration directory which includes all further lint option files.<br />
<br />
; PC_LINT_USER_FLAGS : Additional pc-lint command line options. Some flags of pc-lint cannot be set in option files (most notably -b).<br />
<br />
=== Source ===<br />
<br />
<pre><br />
# This file contains functions and configurations for generating PC-Lint build<br />
# targets for your CMake projects.<br />
<br />
set(PC_LINT_EXECUTABLE "c:/lint/lint-nt.exe" CACHE STRING "full path to the pc-lint executable. NOT the generated lin.bat")<br />
set(PC_LINT_CONFIG_DIR "c:/lint/" CACHE STRING "full path to the directory containing pc-lint configuration files")<br />
set(PC_LINT_USER_FLAGS "-b" CACHE STRING "additional pc-lint command line options -- some flags of pc-lint cannot be set in option files (most notably -b)")<br />
<br />
# a phony target which causes all available *_LINT targets to be executed<br />
add_custom_target(ALL_LINT)<br />
<br />
# add_pc_lint(target source1 [source2 ...])<br />
#<br />
# Takes a list of source files and generates a build target which can be used<br />
# for linting all files<br />
#<br />
# The generated lint commands assume that a top-level config file named<br />
# 'std.lnt' resides in the configuration directory 'PC_LINT_CONFIG_DIR'. This<br />
# config file must include all other config files. This is standard lint<br />
# behaviour.<br />
#<br />
# Parameters:<br />
# - target: the name of the target to which the sources belong. You will get a<br />
# new build target named ${target}_LINT<br />
# - source1 ... : a list of source files to be linted. Just pass the same list<br />
# as you passed for add_executable or add_library. Everything except<br />
# C and CPP files (*.c, *.cpp, *.cxx) will be filtered out.<br />
#<br />
# Example:<br />
# If you have a CMakeLists.txt which generates an executable like this:<br />
#<br />
# set(MAIN_SOURCES main.c foo.c bar.c)<br />
# add_executable(main ${MAIN_SOURCES})<br />
#<br />
# include this file<br />
#<br />
# include(/path/to/pc_lint.cmake)<br />
#<br />
# and add a line to generate the main_LINT target<br />
#<br />
# if(COMMAND add_pc_lint)<br />
# add_pc_lint(main ${MAIN_SOURCES})<br />
# endif(COMMAND add_pc_lint)<br />
#<br />
function(add_pc_lint target)<br />
get_directory_property(lint_include_directories INCLUDE_DIRECTORIES)<br />
get_directory_property(lint_defines COMPILE_DEFINITIONS)<br />
<br />
# let's get those elephants across the alps<br />
# prepend each include directory with "-i"; also quotes the directory<br />
set(lint_include_directories_transformed)<br />
foreach(include_dir ${lint_include_directories})<br />
list(APPEND lint_include_directories_transformed -i"${include_dir}")<br />
endforeach(include_dir)<br />
<br />
# prepend each definition with "-d"<br />
set(lint_defines_transformed)<br />
foreach(definition ${lint_defines})<br />
list(APPEND lint_defines_transformed -d${definition})<br />
endforeach(definition)<br />
<br />
# list of all commands, one for each given source file<br />
set(pc_lint_commands)<br />
<br />
foreach(sourcefile ${ARGN})<br />
# only include c and cpp files<br />
if( sourcefile MATCHES \\.c$|\\.cxx$|\\.cpp$ )<br />
# make filename absolute<br />
get_filename_component(sourcefile_abs ${sourcefile} ABSOLUTE)<br />
# create command line for linting one source file and add it to the list of commands<br />
list(APPEND pc_lint_commands<br />
COMMAND ${PC_LINT_EXECUTABLE}<br />
-i"${PC_LINT_CONFIG_DIR}" std.lnt<br />
"-u" ${PC_LINT_USER_FLAGS}<br />
${lint_include_directories_transformed}<br />
${lint_defines_transformed}<br />
${sourcefile_abs})<br />
endif()<br />
endforeach(sourcefile)<br />
<br />
# add a custom target consisting of all the commands generated above<br />
add_custom_target(${target}_LINT ${pc_lint_commands} VERBATIM)<br />
# make the ALL_LINT target depend on each and every *_LINT target<br />
add_dependencies(ALL_LINT ${target}_LINT)<br />
<br />
endfunction(add_pc_lint)<br />
</pre><br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=PC-Lint&diff=62646PC-Lint2018-04-26T16:22:15Z<p>Brad.king: </p>
<hr />
<div>= CMake script for generating PC-Lint targets =<br />
<br />
''add_pc_lint'' is a CMake macro for generating build targets for PC-Lint.<br />
<br />
If you use it, you will get a build target invoking pc-lint for each source file with the same include directories and preprocessor defines as for the compiler. The lint build target will have the same name as your original build target, but with ''_LINT'' appended. You will also get the build target ALL_LINT which invokes all *_LINT targets. The *_LINT targets will not be built with ALL_BUILD. Only if they are directly built or if ALL_LINT is built.<br />
<br />
This setup integrates PC-Lint into your existing setup. It has been tested with Visual Studio 8 and NMake Makefiles.<br />
<br />
=== Usage ===<br />
<br />
If you want to use this macro, you need:<br />
<br />
* an existing CMake setup for your project<br />
* PC-Lint installed<br />
* configuration files for PC-Lint<br />
<br />
==== Synopsis ====<br />
<br />
add_pc_lint(target source1 [source2 ...])<br />
<br />
;target<br />
:the name of the target to which the sources belong. You will get a new build target named ${target}_LINT<br />
<br />
;source1 source2 ... <br />
:a list of source files to be linted. Just pass the same list as you passed for add_executable or add_library. Everything except C and CPP files (*.c, *.cpp, *.cxx) will be filtered out.<br />
<br />
==== Example ====<br />
<br />
If you have a CMakeLists.txt which generates an executable (or library) like this:<br />
<br />
set(MAIN_SOURCES main.c foo.c bar.c)<br />
add_executable(main ${MAIN_SOURCES})<br />
<br />
include this file (only once, preferrably at the top level CMakeLists.txt)<br />
<br />
include(/path/to/pc_lint.cmake)<br />
<br />
and add a command to generate the main_LINT target<br />
<br />
if(COMMAND add_pc_lint)<br />
add_pc_lint(main ${MAIN_SOURCES})<br />
endif(COMMAND add_pc_lint)<br />
<br />
=== Configuration ===<br />
<br />
The pc_lint.cmake script exports the following CMake cache variables, which you have to adjust using the CMake tools to fit your environment.<br />
<br />
;PC_LINT_EXECUTABLE<br />
:Full path to the pc-lint executable. Not the generated lin.bat. On a standard PC-Lint installation, this path is ''c:/lint/lint-nt.exe''<br />
<br />
;PC_LINT_CONFIG_DIR<br />
:Full path to the directory containing pc-lint configuration files. For each Platform/Compiler/Toolchain, you may want to have a different set of options. If you keep these options in separate directories, you can point this variable to the appropriate one. ''add_pc_lint'' assumes that there is a file called ''std.lnt'' in the configuration directory which includes all further lint option files.<br />
<br />
;PC_LINT_USER_FLAGS<br />
:Additional pc-lint command line options. Some flags of pc-lint cannot be set in option files (most notably -b).<br />
<br />
=== Source ===<br />
<pre><br />
# This file contains functions and configurations for generating PC-Lint build<br />
# targets for your CMake projects.<br />
<br />
set(PC_LINT_EXECUTABLE "c:/lint/lint-nt.exe" CACHE STRING "full path to the pc-lint executable. NOT the generated lin.bat")<br />
set(PC_LINT_CONFIG_DIR "c:/lint/" CACHE STRING "full path to the directory containing pc-lint configuration files")<br />
set(PC_LINT_USER_FLAGS "-b" CACHE STRING "additional pc-lint command line options -- some flags of pc-lint cannot be set in option files (most notably -b)")<br />
<br />
# a phony target which causes all available *_LINT targets to be executed<br />
add_custom_target(ALL_LINT)<br />
<br />
# add_pc_lint(target source1 [source2 ...])<br />
#<br />
# Takes a list of source files and generates a build target which can be used<br />
# for linting all files<br />
#<br />
# The generated lint commands assume that a top-level config file named<br />
# 'std.lnt' resides in the configuration directory 'PC_LINT_CONFIG_DIR'. This<br />
# config file must include all other config files. This is standard lint<br />
# behaviour.<br />
#<br />
# Parameters:<br />
# - target: the name of the target to which the sources belong. You will get a<br />
# new build target named ${target}_LINT<br />
# - source1 ... : a list of source files to be linted. Just pass the same list<br />
# as you passed for add_executable or add_library. Everything except<br />
# C and CPP files (*.c, *.cpp, *.cxx) will be filtered out.<br />
#<br />
# Example:<br />
# If you have a CMakeLists.txt which generates an executable like this:<br />
#<br />
# set(MAIN_SOURCES main.c foo.c bar.c)<br />
# add_executable(main ${MAIN_SOURCES})<br />
#<br />
# include this file<br />
#<br />
# include(/path/to/pc_lint.cmake)<br />
#<br />
# and add a line to generate the main_LINT target<br />
#<br />
# if(COMMAND add_pc_lint)<br />
# add_pc_lint(main ${MAIN_SOURCES})<br />
# endif(COMMAND add_pc_lint)<br />
#<br />
function(add_pc_lint target)<br />
get_directory_property(lint_include_directories INCLUDE_DIRECTORIES)<br />
get_directory_property(lint_defines COMPILE_DEFINITIONS)<br />
<br />
# let's get those elephants across the alps<br />
# prepend each include directory with "-i"; also quotes the directory<br />
set(lint_include_directories_transformed)<br />
foreach(include_dir ${lint_include_directories})<br />
list(APPEND lint_include_directories_transformed -i"${include_dir}")<br />
endforeach(include_dir)<br />
<br />
# prepend each definition with "-d"<br />
set(lint_defines_transformed)<br />
foreach(definition ${lint_defines})<br />
list(APPEND lint_defines_transformed -d${definition})<br />
endforeach(definition)<br />
<br />
# list of all commands, one for each given source file<br />
set(pc_lint_commands)<br />
<br />
foreach(sourcefile ${ARGN})<br />
# only include c and cpp files<br />
if( sourcefile MATCHES \\.c$|\\.cxx$|\\.cpp$ )<br />
# make filename absolute<br />
get_filename_component(sourcefile_abs ${sourcefile} ABSOLUTE)<br />
# create command line for linting one source file and add it to the list of commands<br />
list(APPEND pc_lint_commands<br />
COMMAND ${PC_LINT_EXECUTABLE}<br />
-i"${PC_LINT_CONFIG_DIR}" std.lnt<br />
"-u" ${PC_LINT_USER_FLAGS}<br />
${lint_include_directories_transformed}<br />
${lint_defines_transformed}<br />
${sourcefile_abs})<br />
endif()<br />
endforeach(sourcefile)<br />
<br />
# add a custom target consisting of all the commands generated above<br />
add_custom_target(${target}_LINT ${pc_lint_commands} VERBATIM)<br />
# make the ALL_LINT target depend on each and every *_LINT target<br />
add_dependencies(ALL_LINT ${target}_LINT)<br />
<br />
endfunction(add_pc_lint)<br />
</pre><br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=Really_Cool_CMake_Features&diff=62645Really Cool CMake Features2018-04-26T16:21:39Z<p>Brad.king: </p>
<hr />
<div>CMake is a mature tool with many features, both big and small. Many go unnoticed or are taken for granted. Help us create a comprehensive list of features that make CMake really cool. Please list your addition under the appropriate package: CMake, CTest, or CPack.<br />
<br />
== CMake Features ==<br />
<br />
<br />
* Color output for make<br />
* Progress output for make<br />
* Incremental linking support with vs 8,9 and manifests<br />
* Supports out-of-tree builds<br />
* Auto-rerun of cmake if any cmake input files change (works with vs 8, 9 using ide macros)<br />
* Auto depend information for C++, C, and Fortran<br />
** [http://graphviz.org/ Graphviz] output for visualizing dependency trees<br />
* Full support for library versions <br />
* Full cross platform install system<br />
* Generate project files for major IDEs: Visual Studio, Xcode, Eclipse, KDevelop<br />
** not tied to make, other portable generators like ant possible<br />
* Ability to add custom rules and targets<br />
* Compute link depend information, and chaining of dependent libraries<br />
* Works with parallel make and is fast, can build very large projects like KDE on build farms<br />
* make help, make foo.s, make foo.E, VERBOSE=1 make PROJECT/fast<br />
* Advanced RPATH handling, full support for all kinds of static/shared libs and plugins, no more cryptic foo.la libtool "libraries"<br />
* support for chrpath, i.e. changing the RPATH without need to actually link again<br />
* Works on many host operating systems (a full list would be good)<br />
* Supports many toolchains: GNU, MS, Borland, Sun, also e.g sdcc<br />
* Beta cross compiling, to Linux, Windows, eCos, supercomputers, no OS, from 8bit uCs to 64bit CPUs<br />
* Full dependencies: build a target in some directory, and everything this target depends on will be up to date<br />
* Extensive test suite and nightly builds/test on many platforms<br />
* modular design (e.g. the Find modules, language, toolchain and OS support files) * > easily extendable<br />
* just one tool instead of automake+autoconf+libtool+m4+shell+make<br />
* Good scripting language that supports:<br />
** control structures (conditional, iterative)<br />
** regular expressions, eliminating need for grep+awk+sed+perl<br />
** macros (similar to functions, with counted or vararg parameters)<br />
** portable commands for file and directory manipulation<br />
* Extensive auxiliary cmake modules for finding and simplifying use of popular libraries (boost, sdl, fltk, etc.) and utilities (swig, etc). <br />
* Comes with a GUI layer for easy edition of input variables, both Curses and QT based options.<br />
* Command line support<br />
* it's a native tool, windows devs don't have to deal with POSIX shells, OSX devs can continue to use XCode<br />
* .tar.gz archiving available on all platforms: no need to chase down tar/gzip for Windows<br />
* can create OSX library frameworks<br />
* can create OSX application bundles<br />
* scales well for really, really big projects like KDE<br />
<br />
== CTest Features ==<br />
* Run all or sub-sets of tests for a project<br />
* Submit testing results to Dart 1,2 and CDash<br />
* Run tests that build and run --build-and-test command<br />
* support coverage with gcc, and bullseye coverage tools<br />
* support memory checking with valgrind, purify, and bounds checker<br />
<br />
== CPack Features ==<br />
* Simple Declarative creation of packages/installers using CMake+CPack<br />
* Create Source or Binary packages<br />
* A wealth of supported formats:<br />
** Create professional windows installers with [http://nsis.sourceforge.net/Main_Page NSIS]<br />
** Create tar.gz tar.Z on any platform<br />
** Create self extracting tar.gz .sh files<br />
** Create rpm <br />
** Create Debian .deb files<br />
** Create Cygwin setup packages<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAddUninstallTarget&diff=62644RecipeAddUninstallTarget2018-04-26T16:20:40Z<p>Brad.king: </p>
<hr />
<div>This is a slight hack for adding an uninstall target. It parses the install manifest and removes all of those same files. If your program generates files at runtime, this uninstaller won't even know they exist and will leave them. There are a few assumptions made here, such as that your project has a folder called "cmake" that contains the cmake_uninstall.cmake file. Credit is due to the original author but I've had this one for so long, I can't remember the origins.<br />
<br />
Add this to your top-level CMakeLists.txt:<br />
<br />
<pre><br />
########### Add uninstall target ###############<br />
CONFIGURE_FILE(<br />
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/cmake_uninstall.cmake.in"<br />
"${CMAKE_CURRENT_BINARY_DIR}/cmake/cmake_uninstall.cmake"<br />
IMMEDIATE @ONLY)<br />
ADD_CUSTOM_TARGET(uninstall<br />
"${CMAKE_COMMAND}" -P "${CMAKE_CURRENT_BINARY_DIR}/cmake/cmake_uninstall.cmake") <br />
</pre><br />
<br />
Create this file as cmake_uninstall.cmake into your project's "cmake" folder:<br />
<br />
<pre><br />
IF(NOT EXISTS "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt")<br />
MESSAGE(FATAL_ERROR "Cannot find install manifest: "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt"")<br />
ENDIF(NOT EXISTS "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt")<br />
<br />
FILE(READ "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt" files)<br />
STRING(REGEX REPLACE " " ";" files "${files}")<br />
FOREACH(file ${files})<br />
MESSAGE(STATUS "Uninstalling "$ENV{DESTDIR}${file}"")<br />
IF(EXISTS "$ENV{DESTDIR}${file}")<br />
EXEC_PROGRAM(<br />
"@CMAKE_COMMAND@" ARGS "-E remove "$ENV{DESTDIR}${file}""<br />
OUTPUT_VARIABLE rm_out<br />
RETURN_VALUE rm_retval<br />
)<br />
IF(NOT "${rm_retval}" STREQUAL 0)<br />
MESSAGE(FATAL_ERROR "Problem when removing "$ENV{DESTDIR}${file}"")<br />
ENDIF(NOT "${rm_retval}" STREQUAL 0)<br />
ELSE(EXISTS "$ENV{DESTDIR}${file}")<br />
MESSAGE(STATUS "File "$ENV{DESTDIR}${file}" does not exist.")<br />
ENDIF(EXISTS "$ENV{DESTDIR}${file}")<br />
ENDFOREACH(file)<br />
</pre><br />
<br />
Now, you should be able to run "make install" to install your project and then "make uninstall" to remove the files. <br />
<br />
Credit to the CMake mailing list archives for providing this solution.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAddSoVersionToDLLs&diff=62643RecipeAddSoVersionToDLLs2018-04-26T16:19:56Z<p>Brad.king: </p>
<hr />
<div>When building for platforms that don't allow .so versioning, it's sometimes nice to be able to see at a glance what version of the API the .so library supports. Here's some example code for adding this to non-linux platforms and not breaking linux platforms in the process:<br />
<br />
<pre><br />
SET( GENERIC_DLL_VERSION ${VERSION} )<br />
SET( MYDLL_SOVERSION 1 )<br />
...<br />
ADD_LIBRARY(mydll SHARED ${mydll_SRCS})<br />
target_link_libraries(mydll otherlib)<br />
IF( WIN32 )<br />
SET_TARGET_PROPERTIES( mydll PROPERTIES<br />
OUTPUT_NAME "mydll-${MYDLL_SOVERSION}"<br />
VERSION ${GENERIC_DLL_VERSION} )<br />
ELSE()<br />
SET_TARGET_PROPERTIES( mydll PROPERTIES<br />
VERSION ${GENERIC_DLL_VERSION}<br />
SOVERSION ${MYDLL_SOVERSION} )<br />
ENDIF()<br />
</pre><br />
<br />
You will need to be sure to increment the VERSION and MYDLL_SOVERSION every time the program or the SOVERSION changes (respectively). <br />
One thing I'd like to try in the future is add something to my unit tests that grep the source headers for the API and complain when it's changed to remind me to update the SOVERSION.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAddShortcutToStartMenu&diff=62642RecipeAddShortcutToStartMenu2018-04-26T16:19:36Z<p>Brad.king: </p>
<hr />
<div>If you application builds for multiple platforms and you'd like your application to show up in the Start Menu in Windows XP, add this logic to the end of your CMakeLists.txt file before "include(CPack)":<br />
<br />
<pre><br />
if( WIN32 AND NOT UNIX )<br />
SET(CPACK_PACKAGE_EXECUTABLES "Target_Name" "Target Name")<br />
endif()<br />
</pre><br />
<br />
Now the application shows up with a shortcut in the Start Menu on Windows only with the name "Target Name"<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAppendVersionNumberToInstallpath&diff=62641RecipeAppendVersionNumberToInstallpath2018-04-26T16:19:20Z<p>Brad.king: </p>
<hr />
<div>In some situations, it's necessary to keep older versions of a program along with the newer. Here is a recipe for appending the version number to your install path:<br />
<br />
<pre><br />
IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)<br />
SET(ORIGINAL_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX} CACHE STRING "Default prefix path" FORCE)<br />
ENDIF()<br />
MARK_AS_ADVANCED(ORIGINAL_INSTALL_PREFIX)<br />
<br />
IF( NOT( VERSION VERSION_EQUAL PROJECT_VERSION) )<br />
SET(CMAKE_INSTALL_PREFIX "${ORIGINAL_INSTALL_PREFIX}-${VERSION}" CACHE STRING "Install path" FORCE)<br />
SET(PROJECT_VERSION ${VERSION})<br />
ENDIF()<br />
</pre><br />
<br />
This ensures that the CMAKE_INSTALL_PREFIX is updated whenever the old version number and the new version number doesn't match. This does have some side-effects, such as situations where the user is customizing the CMAKE_INSTALL_PREFIX to some custom location. Such users would need to modify the ORIGINAL_INSTALL_PREFIX instead to ensure that the project is going to the desired place. <br />
<br />
The CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is necessary here because if it's missing, the path becomes recursive and will continue to append ${PROJECT_NAME}-${VERSION} to the path infinitely. The conditional ensures that it only does this once.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAddShortcutToStartMenu&diff=62640RecipeAddShortcutToStartMenu2018-04-26T16:19:05Z<p>Brad.king: </p>
<hr />
<div>If you application builds for multiple platforms and you'd like your application to show up in the Start Menu in Windows XP, add this logic to the end of your CMakeLists.txt file before "include(CPack)":<br />
<br />
<br />
<pre>if( WIN32 AND NOT UNIX )<br />
SET(CPACK_PACKAGE_EXECUTABLES "Target_Name" "Target Name")<br />
endif()</pre><br />
<br />
Now the application shows up with a shortcut in the Start Menu on Windows only with the name "Target Name"<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=GccXmlAutoConfHints&diff=62639GccXmlAutoConfHints2018-04-26T16:18:21Z<p>Brad.king: </p>
<hr />
<div>When converting from autoconf, the generation of "config.h" files can be complex. You may wish to examine the CMake scripts within the gcc-xml project at [http://www.gccxml.org/HTML/Index.html gcc-xml (XML output of gcc's internal representation)]. The project builds a modified gcc compiler using CMake. This is an impressive feat of autoconf conversion. <br />
<br />
For example, the HAVE_THIS/HAVE_THAT defines used within autoconf projects can be overwhelming when converting a large project. Below is a snippet from the "config.h.in" file within gcc-xml:<br />
<br />
<pre><br />
/* Define to 1 if you have the `bcopy' function. */<br />
#cmakedefine HAVE_BCOPY @HAVE_BCOPY@<br />
<br />
/* Define to 1 if you have the `bsearch' function. */<br />
#cmakedefine HAVE_BSEARCH @HAVE_BSEARCH@<br />
<br />
/* Define to 1 if you have the `bzero' function. */<br />
#cmakedefine HAVE_BZERO @HAVE_BZERO@<br />
</pre><br />
<br />
While not a drop-in tool, their scripts are an excellent starting point. ''Be sure to reference the code from their CVS repository instead of the out-of-date tarball listed.''<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=RecipeAppendVersionNumberToInstallpath&diff=62638RecipeAppendVersionNumberToInstallpath2018-04-26T16:16:21Z<p>Brad.king: </p>
<hr />
<div>In some situations, it's necessary to keep older versions of a program along with the newer. Here is a recipe for appending the version number to your install path:<br />
<br />
<pre>IF(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)<br />
SET(ORIGINAL_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX} CACHE STRING "Default prefix path" FORCE)<br />
ENDIF()<br />
MARK_AS_ADVANCED(ORIGINAL_INSTALL_PREFIX)<br />
<br />
IF( NOT( VERSION VERSION_EQUAL PROJECT_VERSION) )<br />
SET(CMAKE_INSTALL_PREFIX "${ORIGINAL_INSTALL_PREFIX}-${VERSION}" CACHE STRING "Install path" FORCE)<br />
SET(PROJECT_VERSION ${VERSION})<br />
ENDIF()</pre><br />
<br />
This ensures that the CMAKE_INSTALL_PREFIX is updated whenever the old version number and the new version number doesn't match. This does have some side-effects, such as situations where the user is customizing the CMAKE_INSTALL_PREFIX to some custom location. Such users would need to modify the ORIGINAL_INSTALL_PREFIX instead to ensure that the project is going to the desired place. <br />
<br />
The CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is necessary here because if it's missing, the path becomes recursive and will continue to append ${PROJECT_NAME}-${VERSION} to the path infinitely. The conditional ensures that it only does this once.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake/ChangeLog&diff=62637CMake/ChangeLog2018-04-26T15:48:40Z<p>Brad.king: Replaced content with "See https://cmake.org/cmake/help/v3.0/release/3.0.0.html"</p>
<hr />
<div>See https://cmake.org/cmake/help/v3.0/release/3.0.0.html</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake_Generating_Testing_Files&diff=62636CMake Generating Testing Files2018-04-26T13:12:01Z<p>Brad.king: /* DartConfiguration.tcl options */</p>
<hr />
<div>==Introduction==<br />
<br />
CTest is a powerful testing client compatible with<br />
[http://public.kitware.com/Dart Dart] Dashboard system. It is distributed as a<br />
part of [http://www.cmake.org CMake] but can be used with or without CMake.<br />
This tutorial explains some background behind the testing with CTest and the<br />
process of generating CTest testing files.<br />
<br />
==CTest Overview==<br />
<br />
CTest currently uses the old Dart input configuration file. New input format is<br />
being developed, but the old format will be valid in the future. For legacy<br />
purposes, the input files are called ''DartConfiguration.tcl'', and<br />
''DartTestfile.txt''. ''DartConfiguration.tcl'' describes the system on which<br />
tests are performed, while ''DartTestfile.txt'' provides the list of tests.<br />
<br />
CTest reads ''DartConfiguration.tcl'' and depending on the options provided it<br />
performs certain stage of testing.<br />
<br />
===Description Of The System===<br />
<br />
Even though the extension of ''DartConfiguration.tcl''<br />
file is ''.tcl'', it is not TCL file. It is simply list of key/value pairs.<br />
Line starting with ''#'' are considered comments and are ignored. This file has to appear at the toplevel directory of the project's build directory.<br />
<br />
Example ''DartConfiguration.tcl'' file is:<br />
<br />
<pre><br />
SourceDirectory: /path/to/project/source/directory<br />
BuildDirectory: /path/to/project/build/directory<br />
CVSUpdateOptions: -d -A -P<br />
Site: my-system-name<br />
BuildName: build-name<br />
DropSite: public.kitware.com<br />
DropLocation: /cgi-bin/HTTPUploadDartFile.cgi <br />
DropMethod: http<br />
TriggerSite: http://public.kitware.com/cgi-bin/Submit-Random-TestingResults.pl<br />
NightlyStartTime: 21:00:00 EDT<br />
ConfigureCommand: "/path/to/source/directory/Project/configure"<br />
MakeCommand: /usr/bin/make -i<br />
CVSCommand: /usr/bin/cvs<br />
CoverageCommand: /usr/bin/gcov<br />
TimeOut: 1500<br />
</pre><br />
<br />
====DartConfiguration.tcl options====<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Key !! Description !! Example value<br />
|-<br />
| SourceDirectory || Path to the source directory of the project. Used for CVS or SVN update. || /path/to/project/source/directory<br />
|-<br />
| BuildDirectory || Path to the build directory of the project. This is where Testing results will go and all testing commands will be run in this directory. || /path/to/project/build/directory<br />
|-<br />
| Site || Refers to the system name used to distinguish the dashboard entry. || my-system-name<br />
|-<br />
| BuildName || A breif description of the system and the project. || FLTK-Linux-g++334<br />
|-<br />
| DropSite ||rowspan=4| ''DropSite'', ''DropLocation'', ''DropMethod'', and ''TriggerSite'' describe the location where test results are submitted. For more information about CTest submission, please look at: [[CTest:Submission_Issues]]. The location specified in the example is the [http://public.kitware.com/dashboard.php?name=public Public Dashboard] provided as a service by [http://www.kitware.com Kitware]. || public.kitware.com<br />
|-<br />
| DropLocation|| /cgi-bin/HTTPUploadDartFile.cgi <br />
|-<br />
| DropMethod || http<br />
|-<br />
| TriggerSite || http://public.kitware.com/cgi-bin/Submit-Random-TestingResults.pl<br />
|-<br />
| NightlyStartTime ||A the time when Nightly dashboard starts. This is useful when doing Nightly dashboard. The Nightly dashboard will update the source directory to the state at given time. || 21:00:00 EDT<br />
|-<br />
| UpdateCommand || Command used to update the project during the Update stage. || /usr/bin/cvs<br />
|-<br />
| UpdateOptions || Additional options passed to update command || -d -A -P<br />
|-<br />
| UpdateType || Type of update used. Currently only CVS and SVN are valid types || cvs<br />
|-<br />
| ConfigureCommand || Command run during the Configure stage || "/path/to/source/directory/Project/configure"<br />
|-<br />
| MakeCommand || Command run during the Build stage ||/usr/bin/make -i<br />
|-<br />
| CoverageCommand || Command used for the Coverage testing. Currently only GCC gcov is supported. || /usr/bin/gcov<br />
|-<br />
| TimeOut || A maximum time the test will be allowed to run. Once test time expires, the test will be interrupted and the status will be ''Timeout''. ||1500<br />
|}<br />
<br />
===Description of Tests===<br />
<br />
For legacy purposes and for compatibility with ''Dart'', the test description<br />
file is called ''DartTestfile.txt''. It is parsed by full CMake parser, but the<br />
only CMake commands that are available are ''SUBDIRS'' and ''ADD_TEST''. Example<br />
''DartTestfile.txt'' is:<br />
<br />
<pre><br />
ADD_TEST(testProcess-1 "/my/project/testProcess" "1")<br />
ADD_TEST(testProcess-2 "/my/project/testProcess" "2")<br />
ADD_TEST(testProcess-3 "/my/project/testProcess" "3")<br />
ADD_TEST(testProcess-4 "/my/project/testProcess" "4")<br />
ADD_TEST(testProcess-5 "/my/project/testProcess" "5")<br />
ADD_TEST(testProcess-6 "/my/project/testProcess" "6")<br />
</pre><br />
<br />
Each of the ''ADD_TEST'' adds the test for CTest. The first argument is the<br />
unique name of test. It should be unique, so that it can be differentiated<br />
among all results. The second argument is the executable run as a part of the<br />
test. This is followed by arbitrary number of arguments for the executable.<br />
Test executables can be built as a part of the project (via add_executable), <br />
or a system executable can be used. For example, to test a ''Python'' feature:<br />
<br />
<pre><br />
ADD_TEST(testTkInter "/usr/bin/python" "-c" "import Tkinter")<br />
</pre><br />
<br />
It is a good practice to specify full path to the executable name, since that<br />
way CTest will always pick the desired executable. For example, let say the<br />
test executable name is ''python'' but there is a python installed on the<br />
system, the CTest may pick either the ''python'' executable built by our build<br />
process or use the installed one.<br />
<br />
===Group Tests in Subdirectories===<br />
<br />
Project tests are usually organized into some structure based on the part of the project they test. For example, if the project contains some common code, IO code, processing code, and GUI code, there may be group of tests for each subsection. Common way of organizing this would be in subdirectories. For example, let say the project has the following directory structure:<br />
<br />
<pre><br />
/Project<br />
/Common<br />
/IO<br />
/Processing<br />
/GUI<br />
</pre><br />
<br />
It is fairly easy to reproduce this structure for testing:<br />
<br />
<pre><br />
/Project<br />
/Testing<br />
/Common<br />
/IO<br />
/Processing<br />
/GUI<br />
</pre><br />
<br />
CTest will not automatically search all subdirectories and find all<br />
''DartTestfile.txt''. The project needs to tell it where the tests are. This<br />
can be achieved using ''SUBDIRS'' command in ''DartTestfile.txt''. An example use of ''SUBDIRS'' command is:<br />
<br />
<pre><br />
SUBDIRS(Testing/Common)<br />
SUBDIRS(Testing/IO)<br />
SUBDIRS(Testing/Processing Testing/GUI)<br />
</pre><br />
<br />
The arguments to the ''SUBDIRS'' command are subdirectories containing the<br />
tests. If this file is placed in the top of our project, CTest will search for<br />
files ''DartTestfile.txt'' inside directories /.../Project/Testing/Common,<br />
/.../Project/Testing/IO, and so on to /.../Project/Testing/GUI.<br />
<br />
==Generating Testing Files==<br />
<br />
Testing files ''DartConfiguration.tcl'' and all ''DartTestfile.txt' must be<br />
generated in the same tree as the CTest is run. In most cases this is the build<br />
tree of the project. Since the testing files contain build and system specific<br />
information, they should be generated as a part of testing process and not<br />
permanently part of source code.<br />
<br />
===Using CMake===<br />
<br />
CMake has a automated way of generating CTest input files. There are three pieces to performing testing:<br />
<br />
<pre><br />
ENABLE_TESTING()<br />
</pre><br />
<br />
Enables testing for the project. This command will gather all tests and produce<br />
''DartTestfile.txt'' files with appropriate ''ADD_TEST'' and ''SUBDIRS''<br />
commands.<br />
<br />
<pre><br />
INCLUDE(Dart)<br />
</pre><br />
<br />
Including ''Dart'' CMake module will generate default ''DartConfiguration.tcl''<br />
file, which will contain information about updating, configuring, and building<br />
the project.<br />
<br />
<pre><br />
ADD_TEST(test1 ${EXECUTABLE_OUTPUT_PATH}/test1)<br />
</pre><br />
<br />
Describes test that will be put in ''DartTestfile.txt''. The syntax of ADD_TEST on CMake level is the same as once it is written in ''DartTestfile.txt''. <br />
<br />
More details about how to generate test files with CMake is described in<br />
[[CMake Testing With CTest|Testing With CTest]] tutorial.<br />
<br />
===Without Using CMake===<br />
<br />
CTest is distributed together with CMake, but it can be used independently. The<br />
''DartConfiguration.tcl'' file can be easily generated using ''autoconf'' or<br />
any other tool, or even written by hand. Whatever the method of generating that<br />
file, the author has to make sure all the necessary information is written in<br />
it. Same goes for ''DartTestfile.txt'' files.<br />
<br />
==Conclusion==<br />
<br />
Though we consider CMake to be a great build configuration tool, CTest can be<br />
used without CMake. Because of its simplicity, it can be added to any project<br />
without changing the rest of the project development. Using a small number of<br />
configuration files, CTest can easily automate most if not all of the commonly<br />
used testing procedures.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=BuildingPythonWithCMake&diff=62634BuildingPythonWithCMake2018-04-25T18:55:30Z<p>Brad.king: </p>
<hr />
<div>=Building Python 2.5.1=<br />
<br />
Get the Python sources for release 2.5.1, e.g. from http://www.python.org/download/ . <br />
If you are using Python 2.5.1 you'll need to apply the following patch, otherwise Python doesn't build with dynamic loading disabled and Unicode disabled: <br />
[http://www.cmake.org/Wiki/images/d/dd/Python-2.5.1-build-without-shared-libs-and-unicode.diff Python-2.5.1-build-without-shared-libs-and-unicode.diff]<br />
<br />
There are two ways to get the CMake files for building Python:<br />
<br />
* you can download a snapshot here: [http://www.cmake.org/Wiki/images/b/b9/Python-2.5.1-cmakefiles-2.tar.gz Python-2.5.1-cmakefiles-2.tar.gz].<br />
<br />
Unpack that file and copy them over to the Python source directory, so that the toplevel CMakeLists.txt ends up in<br />
the toplevel Python directory.<br />
<br />
* you can download the CMake files using cvs<br />
<br />
The CMake files for building Python 2.5.1 are in the ParaView3 cvs, in the branch Python-2_5_1-BRANCH.<br />
You can get them like this:<br />
<pre><br />
$ cvs -d :pserver:anoncvs@www.paraview.org:/cvsroot/ParaView3 login<br />
<empty password><br />
$ cvs -d :pserver:anoncvs@www.paraview.org:/cvsroot/ParaView3 co -d CMakeBuildForPython -r Python-2_5_1-BRANCH ParaView3/Utilities/CMakeBuildForPython<br />
</pre><br />
<br />
Then copy these files over to the Python source directory, so that the toplevel CMakeLists.txt ends up in<br />
the toplevel Python directory.<br />
<br />
=Building svn Python or Python >= 2.6.0=<br />
<br />
With Python from svn (not Python 3000) or Python 2.6.0 (not released yet, September 2007), the patch mentioned above for handling <br />
unicode and disabled dynamic loading isn't necessary anymore.<br />
Here's how you can get Python from Python svn and the CMake files for Python, which are in ParaView3 cvs, HEAD;<br />
<pre><br />
$ svn co http://svn.python.org/projects/python/trunk python-with-cmake<br />
$ cvs -d :pserver:anoncvs@www.paraview.org:/cvsroot/ParaView3 login<br />
<empty password><br />
$ cvs -d :pserver:anoncvs@www.paraview.org:/cvsroot/ParaView3 co -d python-with-cmake ParaView3/Utilities/CMakeBuildForPython <br />
</pre><br />
<br />
The commands shown above will check out Python and the CMake files in the same directory, which will be both a CVS and a svn working directory at the same time. While this is a bit unusual it works, since svn and CVS use different meta data directories (.svn/ vs. CVS/).<br />
<br />
= Building Python 2.7.1 to 2.7.3 =<br />
<br />
The build system of "David Sansome" looks very promising. <br />
<br />
It allows a lot of flexibility in the way python can be built and embedded in existing application.<br />
<br />
See https://github.com/davidsansome/python-cmake-buildsystem<br />
<br />
=Platform specific build notes=<br />
<br />
==Building Python for Linux or Windows==<br />
<br />
Just run CMake on it as usual, then make, make install. Under Windows this is tested with VisualStudio 2003.<br />
Under Windows the tests in ConfigureChecks.cmake are not actually executed, but the pyconfig.h for Windows which is part of the Python<br />
sources is used as is. This is actually not necessary, the tests could be executed the same way as they are executed under Windows, <br />
but to get this working probably some flags, include files etc. have to be adjusted, and I didn't have the time to do this yet.<br />
As a difference to the original Python build for Windows not all modules are built into a huge python.dll, but instead they are built as separate plugins (as under Linux).<br />
<br />
==Building Python for other operating systems==<br />
<br />
Building Python using CMake for other operating systems like OS X, *BSD etc. shouldn't require a lot of work, maybe it already works<br />
out of the box. Probably some configure checks have to be tweaked.<br />
<br />
<br />
==Cross compiling Python for BlueGene/L==<br />
<br />
Cross compiling Python for BlueGene is easy, since in python-with-cmake/CMake/ there is a file TryRunResults-Python-bgl-gcc.cmake,<br />
which contains the results for the TRY_RUN() tests which are executed by CMake when configuring Python. Since <br />
we are cross compiling CMake can't actually run these tests, but the results have to be supplied manually.<br />
This is done in this case by preloading the CMake cache using the mentioned file:<br />
<br />
<pre><br />
~/src/python-with-cmake/ $ <br />
~/src/python-with-cmake/ $ mkdir build-bgl<br />
~/src/python-with-cmake/~$ cd build-bgl<br />
~/src/python-with-cmake/build-bgl/ $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-BlueGeneL-gcc.cmake -DCMAKE_INSTALL_PREFIX=~/bgl-install -C ../CMake/TryRunResults-Python-bgl-gcc.cmake ..<br />
...<br />
~/src/python-with-cmake/build-bgl/ $ make<br />
...<br />
~/src/python-with-cmake/build-bgl/ $ make install<br />
...<br />
</pre><br />
<br />
==Cross compiling Python for Cray Xt3/ Catamount==<br />
<br />
Cross compiling Python for Cray Xt3/Catamount is easy, since in python-with-cmake/CMake/ there is a file TryRunResults-Python-catamount-gcc.cmake,<br />
which contains the results for the TRY_RUN() tests which are executed by CMake when configuring Python. Since <br />
we are cross compiling CMake can't actually run these tests, but the results have to be supplied manually.<br />
This is done in this case by preloading the CMake cache using the mentioned file:<br />
<br />
<pre><br />
~/src/python-with-cmake/ $ <br />
~/src/python-with-cmake/ $ mkdir build-catamount-gcc<br />
~/src/python-with-cmake/~$ cd build-catamount-gcc<br />
~/src/python-with-cmake/build-catamount-gcc/ $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-Catamount-gcc.cmake -DCMAKE_INSTALL_PREFIX=~/catamount-install -C ../CMake/TryRunResults-Python-catamount-gcc.cmake ..<br />
...<br />
</pre><br />
The python module <tt>pwd</tt> has to be disabled by setting MODULE_pwd_ENABLE to OFF, since the getpw*() functions are not available under Catamount.<br />
<pre><br />
~/src/python-with-cmake/build-catamount/ $ make<br />
...<br />
~/src/python-with-cmake/build-catamount/ $ make install<br />
...<br />
</pre><br />
<br />
When linking it all together there are a lot of warnings about posix_* functions, where the linker warns that they will fail at runtime. They come from the posix module. But this has to be built, it's presence itself is used by python to detect that it's running on a POSIX-like platform.<br />
<br />
==Cross compiling Python for another platform==<br />
<br />
<pre><br />
~/src/python-with-cmake/ $ <br />
~/src/python-with-cmake/ $ mkdir build-ecos<br />
~/src/python-with-cmake/~$ cd build-ecos<br />
~/src/python-with-cmake/build-ecos/ $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-eCos-synth.cmake -DCMAKE_INSTALL_PREFIX=~/ecos-install ..<br />
...<br />
</pre><br />
<br />
This will finish with two errors, one for each TRY_RUN(), since this is cross compiling and CMake doesn't try to execute<br />
the executables. CMake will have created a file TryRunResults.cmake, <br />
This will finish with two errors:<br />
<pre><br />
-- Performing Test HAVE_BROKEN_NICE<br />
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriatly:<br />
HAVE_BROKEN_NICE_EXITCODE (advanced)<br />
For details see ~/src/python-with-cmake/build-ecos/TryRunResults.cmake<br />
-- Performing Test HAVE_BROKEN_NICE - Failed<br />
-- Performing Test HAVE_BROKEN_POLL<br />
CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriatly:<br />
HAVE_BROKEN_POLL_EXITCODE (advanced)<br />
For details see ~/src/python-with-cmake/build-ecos/TryRunResults.cmake<br />
-- Performing Test HAVE_BROKEN_POLL - Failed<br />
</pre><br />
<br />
These are two system tests, where cmake used TRY_RUN() to test an executable, but since they are cross compiled, it didn't try to run them but instead produced these error messages.<br />
As the messages say have a look at ~/src/python-with-cmake/build-ecos/TryRunResults.cmake .<br />
You will find the executables which were not run in the build directory, named cmTryCompileExec-HAVE_BROKEN_NICE_EXITCODE and cmTryCompileExec-HAVE_BROKEN_POLL_EXITCODE. You can try to run them on the target to see what there exit code is and put these<br />
results into the TryRunResults.cmake file. After that you should copy this file to a safe place, otherwise it gets <br />
overwritten on the next CMake run and your changes are lost.<br />
Then use this file to preload the CMake cache with the results from the TRY_RUN():<br />
<pre><br />
~/src/python-with-cmake/build-ecos/ $ cmake -C ../CMake/TryRunResults-Python-ecos-synth.cmake ..<br />
...<br />
~/src/python-with-cmake/build-ecos/ $ make<br />
...<br />
~/src/python-with-cmake/build-ecos/ $ make install<br />
...<br />
</pre><br />
<br />
=Current status=<br />
<br />
==What works==<br />
* Builds on Linux, Windows and cross compiles to eCos, IBM BlueGene/L and Cray Xt3/Catamount<br />
* the python library can be built as shared or static library, RPATH is supported<br />
* each module can be enabled and disabled separatly<br />
* on systems without shared libs everything is build static, modules are linked into the python library<br />
* packages can be created using cpack (or "make package"): rpm, deb, tgz, stgz, zip, nsis and more<br />
<br />
==TODO==<br />
* Enable the configure checks on Windows, so the premade pyconfig.h file can go away.<br />
* Trying to build it on other platforms like *BSD, Apple. This shouldn't be much work.<br />
* Adding the remaining modules to the build. Should be just work, no major problems expected.<br />
* Add rules to bytecompile (or how it is called) the python modules to .pyc files<br />
* The python executable is currently installed with the version number in their name.<br />
<br />
=Potential problems=<br />
<br />
==Module not found==<br />
<br />
If the Python executable and the python library have been built and installed successfully and you can execute<br />
simple things, it still can happen that some modules are not found.<br />
Currently not all Python modules are built and not everything is installed. In this case have a look at python-with-svn/CMakeLists.txt and search in the list of ADD_PYTHON_MODULE() commands if your module is included. Some modules are disabled by default, you can enable building them by setting the option BUILD_UNTESTED_MODULES to TRUE. Other modules are still completely missing. <br />
If this is the case, figure out what the source files for this module are and add it to this list.<br />
If it is built and installed, but Python still doesn't find it, it's time for debugging. A good start might be python-with-svn/Python/import.c .<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake_Editors_Support&diff=62633CMake Editors Support2018-04-25T18:24:59Z<p>Brad.king: /* CMake Editor Modes */</p>
<hr />
<div>==CMake Editor Modes==<br />
<br />
There are CMake syntax highlighting and indentation supports for many editors:<br />
<br />
* '''[http://www.eclipse.org/cdt/ Eclipse]''' There are two plugins for Eclipse:<br />
** The [https://github.com/15knots/cmakeed CMakeEd] plugin for Eclipse provides syntax coloring and content assist for editing CMakeLists.txt and any file ending in a .cmake extension. It also integrates the CMake command reference documentation into the Eclipse Help system. This plugin does NOT do project management for you or generate CMake files for you. You are still responsible for this part. CMakeEd just makes writing the CMakeLists.txt files easier. Unfortunately, the built-in documentation has not been updated for several years and is badly out of date.<br />
** The [https://marketplace.eclipse.org/content/cmake4eclipse cmake4eclipse] plugin generates the build scripts when you build the project from eclipse -- no need to manually invoke cmake with the CDT generator. It does not provide project management, your <tt>CMakeLists.txt</tt> files control the build. The plugin comes with a Language Settings Provider that feeds (non standard) include paths and pre-processor symbols defined in your CMake scripts to the CDT-Indexer.<br />
** The [http://www.cmakebuilder.com/ CMakeBuilder] plugin provides a user friendly interface to easily manage CMake-based projects, with the following features: advanced parser, Advanced CMake outline, CMakeBuilder perspective, symbol table and environment inspector, CMake files editor with syntax highlighting, code assist, wizard-oriented project management, Project Nature CMakeBuilder for CDT projects, and incremental project builders.<br>As of 2017, this '''seems to be [https://marketplace.eclipse.org/content/cmakebuilder dead]''': No downloads page, apparently no downloads in the past year.<br />
** More plugins can be found in the '''[https://marketplace.eclipse.org/search/site/cmake Eclipse Marketplace]'''.<br />
* Eclipse C/C++ Development Tooling (CDT) 9.2.0 claims to provide an experimental [https://projects.eclipse.org/projects/tools.cdt/releases/9.2.0 CMake feature].<br />
** '''[[Eclipse_CDT4_Generator|Here]]''' you find documentation how to use the Eclipse CDT project generator of CMake.<br />
** '''[[CMake:Eclipse_UNIX_Tutorial|Here]]''' you find documentation how to use Eclipse with the regular Makefile generator of CMake (for versions < 2.6 of CMake).<br />
<br />
* '''[http://www.kdevelop.org KDevelop 4]''' supports CMake-based projects natively.<br />
<br />
* '''[https://www.jetbrains.com/clion/ CLion]''', though not free, uses CMake-based projects natively.<br />
<br />
* '''[http://qt-project.org/wiki/category:tools::qtcreator QtCreator]''' supports CMake-based projects [https://qt-project.org/doc/qtcreator-2.8/creator-project-cmake.html natively since version 1.1].<br />
<br />
* '''[http://www.netbeans.org NetBeans]''' supports CMake-based projects [http://forums.netbeans.org/ntopic26390.html natively since version 6.8].<br />
<br />
* '''[http://www.gnu.org/software/emacs Emacs]''': See the [[CMake/Editors/Emacs|CMake Emacs Support]] page.<br />
<br />
* '''Enscript''' [http://tristancarel.com/pub/patches/enscript/cmake.st syntax highlighting rules]. To enable it:<br />
*# copy <tt>cmake.st</tt> in the <tt>hl/</tt> directory.<br />
*#add the following in the <tt>namerules</tt> section of the <tt>hl/enscript.st</tt> file:<br />
<br />
<pre><br />
/CMakeLists\.txt/ cmake;<br />
/\.cmake.*$/ cmake;<br />
/\.ctest.*$/ cmake;<br />
</pre><br />
<br />
* '''[http://www.lugaru.com Epsilon]''' has a CMake [http://lugaru.com/ftp/for-v13/cmake.e extension] that supports syntax highlighting, indentation, and auto-completion of expressions for control statements such as if-else-endif, foreach-endforeach, and while-endwhile.<br />
<br />
* '''[http://www.geany.org Geany]''' added CMake support in [http://www.geany.org/Main/20090215 version 0.16]<br />
<br />
* '''[http://kate.kde.org Kate]''', '''KWrite''', '''[http://www.kdevelop.org KDevelop]''' and all other [http://www.kde.org KDE] applications, which use the kate text-editing component support cmake syntax highlighting since KDE 3.4.<br />
<br />
* '''NEdit''' [http://www.cmake.org/Wiki/images/c/c6/NEditCMakeHighlighting-0001.tar.gz syntax highlighting support] was added by [http://public.kitware.com/pipermail/cmake/2007-May/014267.html Philippe Poilbarbe]<br />
<br />
* '''[http://notepad-plus.sourceforge.net/uk/site.htm Notepad++]''' added CMake support in version 4.1<br />
<br />
* '''[http://scintilla.sourceforge.net/SciTEDownload.html SciTE]''' version 1.73 has CMake support. To enable the feature edit SciTEGlobal.Properties and remove the comment before the CMake lines.<br />
<br />
* '''[http://www.sublimetext.com/ Sublime Text]''' Sublime Text is a sophisticated text editor for code, markup and prose. You'll love the slick user interface, extraordinary features and amazing performance. CMake synatx support is provided through the [https://sublime.wbond.net/ Package Control] and the [https://sublime.wbond.net/packages/CMake CMake Package].<br />
<br />
* '''[http://www.macromates.com TextMate]''' is a wonderful text editor for OS X. [http://www.bluequartz.net/binaries/CMake.tmbundle.zip CMake Bundle]. This plugin adds syntax highlighting for CMake files and rudimentary completion for command, properties and cmake variables.<br />
<br />
* '''UltraEdit''' syntax highlighting [http://www.cmake.org/Wiki/images/5/56/UltraEditWordfile.tar.gz word file.]<br />
<br />
* '''VIM''' [http://cmake.org/gitweb?p=cmake.git;a=blob_plain;hb=master;f=Docs/cmake-syntax.vim syntax highlighting] and [http://cmake.org/gitweb?p=cmake.git;a=blob_plain;hb=master;f=Docs/cmake-indent.vim indentation mode]. To enable indentation, copy indentation file to your .vim/indent directory, syntax highlighting file to your .vim/syntax directory and add the following to your .vimrc:<br />
<br />
<pre><br />
:autocmd BufRead,BufNewFile *.cmake,CMakeLists.txt,*.cmake.in runtime! indent/cmake.vim <br />
:autocmd BufRead,BufNewFile *.cmake,CMakeLists.txt,*.cmake.in setf cmake<br />
:autocmd BufRead,BufNewFile *.ctest,*.ctest.in setf cmake<br />
</pre><br />
<br />
* '''Visual Studio 2010 Professional''' and above have two extensions available for editing CMake files. [http://code.google.com/p/vissemee Vissemee] provides syntax highlighting for CMake. [http://cmaketools.codeplex.com CMake Tools for Visual Studio] provides both syntax highlighting and IntelliSense for CMake.<br />
<br />
* '''Visual Studio 2017''' and above [https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/ natively support] CMake projects.<br />
<br />
==Creating New Editor Mode==<br />
<br />
The best way to start is to check the logic in existing ones. Make sure to enable indentation for files that match the following file names:<br />
<br />
* CMakeLists.txt<br />
* *.cmake<br />
* *.cmake.in<br />
* *.ctest<br />
* *.ctest.in<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMakeForFortranExample&diff=62632CMakeForFortranExample2018-04-25T18:24:21Z<p>Brad.king: </p>
<hr />
<div>CMake is perfectly capable of handling Fortran code; however, examples are less abundant than for C or C++. In the example below we write a very small [[CMakeLists.txt]] to wrap a simple Fortran project. <br />
<br />
The motivation for this was to easily compile Fortran code that came with the [http://www.igs.cnrs-mrs.fr/elnemo/NORMA/ NORMA] package. The distribution NORMA-1.0.tgz was downloaded and unpacked. [[#Example CMakeLists.txt|following <tt>CMakeLists.txt</tt>]] was placed into the <tt>./software</tt> directory where the NORMA sources are stored.<br />
<br />
To build one would typically create a build directory at the same level as <tt>software</tt>:<br />
<pre><br />
mkdir build && cd build<br />
ccmake ../software<br />
make<br />
make install<br />
</pre><br />
and then configure, build and install. <br />
<br />
The project is very simple:<br />
* There are only a few fortran source code files in the software directory.<br />
* There are no library dependencies.<br />
* Executables are typically installed in a bin directory in the package itself (i.e. <tt>NORMA/bin</tt>) although the user is free to to change the installation prefix.<br />
* Two shell scripts are also installed alongside.<br />
<br />
The <tt>CMakeLists.txt</tt> is commented and [[#Comments on CMakeLists.txt|additional comments]] can be found after it.<br />
<br />
== Example CMakeLists.txt ==<br />
<pre># CMake project file for NORMA<br />
<br />
cmake_minimum_required (VERSION 2.6)<br />
project (NORMA)<br />
enable_language (Fortran)<br />
<br />
# make sure that the default is a RELEASE<br />
if (NOT CMAKE_BUILD_TYPE)<br />
set (CMAKE_BUILD_TYPE RELEASE CACHE STRING<br />
"Choose the type of build, options are: None Debug Release."<br />
FORCE)<br />
endif (NOT CMAKE_BUILD_TYPE)<br />
<br />
# default installation<br />
get_filename_component (default_prefix ".." ABSOLUTE)<br />
set (CMAKE_INSTALL_PREFIX ${default_prefix} CACHE STRING<br />
"Choose the installation directory; by default it installs in the NORMA directory."<br />
FORCE)<br />
<br />
# FFLAGS depend on the compiler<br />
get_filename_component (Fortran_COMPILER_NAME ${CMAKE_Fortran_COMPILER} NAME)<br />
<br />
if (Fortran_COMPILER_NAME MATCHES "gfortran.*")<br />
# gfortran<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-funroll-all-loops -fno-f2c -O3")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-fno-f2c -O0 -g")<br />
elseif (Fortran_COMPILER_NAME MATCHES "ifort.*")<br />
# ifort (untested)<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-f77rtl -O3")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-f77rtl -O0 -g")<br />
elseif (Fortran_COMPILER_NAME MATCHES "g77")<br />
# g77<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-funroll-all-loops -fno-f2c -O3 -m32")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-fno-f2c -O0 -g -m32")<br />
else (Fortran_COMPILER_NAME MATCHES "gfortran.*")<br />
message ("CMAKE_Fortran_COMPILER full path: " ${CMAKE_Fortran_COMPILER})<br />
message ("Fortran compiler: " ${Fortran_COMPILER_NAME})<br />
message ("No optimized Fortran compiler flags are known, we just try -O2...")<br />
set (CMAKE_Fortran_FLAGS_RELEASE "-O2")<br />
set (CMAKE_Fortran_FLAGS_DEBUG "-O0 -g")<br />
endif (Fortran_COMPILER_NAME MATCHES "gfortran.*")<br />
<br />
<br />
# build executables<br />
set (NMPROGRAMS "diagstd" "diagrtb" "proj_modes_bin" "pdbmat")<br />
set (EXECUTABLES "NORMA.exe" ${NMPROGRAMS})<br />
set (SCRIPTS "gen_pert.sh" "pert_multi_mode.sh")<br />
<br />
add_executable ("NORMA.exe" "NORMA.f")<br />
foreach (p ${NMPROGRAMS})<br />
add_executable (${p} "${p}.f")<br />
endforeach (p)<br />
<br />
# install executables and scripts<br />
install (TARGETS ${EXECUTABLES} <br />
RUNTIME DESTINATION "bin")<br />
install (PROGRAMS ${SCRIPTS}<br />
DESTINATION "bin") <br />
</pre><br />
<br />
== Comments on CMakeLists.txt ==<br />
* Use cmake v2.6 or better for [[CMake Fortran Issues|optimum Fortran support]].<br />
* Make sure that we build a RELEASE by default (and let the user know in the GUI); uses example code from the docs.<br />
* Set the default prefix to the non-standard installation scheme in which one installs all component into the package directory. This directory is assumed to be one above relative the build directory. The full canonical path is obtained with the [http://www.cmake.org/cmake/help/cmake2.6docs.html#command:get_filename_component get_filename_component] function.<br />
* As it is typical for scientific Fortran code, the compiler optimizations are fairly specific. Here we are trying to detect a few common ones (gfortran, Intel ifort, g77) and set the compile options accordingly. If all else fails we use -O2 and hope for the best (but let the user know).<br />
* The <tt>NORMA.exe</tt> binary is built from the source <tt>NORMA.f</tt> so we have to say this explicitly with the <pre>add_executable ("NORMA.exe" "NORMA.f")</pre>line but the other binaries are simply built from corresponding .f files and we write this as a simple foreach-loop.<br />
* Executables are installed in the <tt>bin</tt> dir (which is relative to the prefix).<br />
* Finally, scripts are copied to the <tt>bin</tt> directory, too.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=62627CMake:CPackPackageGenerators2018-04-24T19:00:12Z<p>Brad.king: /* CPack RPM generators specific settings */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
CPack may generate several kind of package on behalf of various ''CPack Generators''. All generators share common properties explained below. Some if not all generators do have specific features or restriction which are explained in specific sections.<br />
<br />
Since CPack 2.8.8, CPack has builtin documentation just like CMake so that one can use:<br />
<br />
<pre><br />
cpack --help-variable-list<br />
cpack --help-variable <VARNAME><br />
cpack --help-command-list<br />
cpack --help-command <CMDNAME><br />
...<br />
cpack --help<br />
</pre><br />
<br />
in order to get specific documentation. This [http://www.cmake.org/Wiki/CMake_builtin_documentation_handling builtin documentation] should be the most up to date documentation for CPack.<br />
The current Wiki is a convenient place to find informations but may not be as up to date as the builtin doc.<br />
<br />
If ever you find undocumented variable and/or innaccurate documentation please file a [http://public.kitware.com/Bug/main_page.php bug report].<br />
The main part of CPack variable or command documentation may be found in CPack<GEN>.cmake file in the CMake source, the documentation is extracted from those files automatically and dynamically by CPack, so you can submit a documentation patch using one of those files.<br />
<br />
== Overall usage (common to all generators) ==<br />
<br />
Information about CPACK_xxx variables used for CPack configuration<br />
may be found there: [http://www.cmake.org/Wiki/CMake:CPackConfiguration CPackConfiguration]<br />
<br />
The CPACK_GENERATOR variable has different meanings in different contexts. In your CMakeLists.txt file, CPACK_GENERATOR is a '''list of generators''': when run with no other arguments, CPack will iterate over that list and produce one package for each generator. In a CPACK_PROJECT_CONFIG_FILE, though, CPACK_GENERATOR is a '''string naming a single generator'''. If you need per-cpack-generator logic to control '''other''' cpack settings, then you need a CPACK_PROJECT_CONFIG_FILE. For example it may be used to switch on/off [http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior component packaging] for a specific generator.<br />
<br />
The CMake source tree itself contains a CPACK_PROJECT_CONFIG_FILE. See the top level file [http://cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeCPackOptions.cmake.in;hb=HEAD CMakeCPackOptions.cmake.in] for an example.<br />
<br />
If set, the CPACK_PROJECT_CONFIG_FILE is included automatically on a per-generator basis. It only needs to contain overrides.<br />
<br />
Here's how it works:<br />
# cpack runs<br />
# it includes CPackConfig.cmake (usually found in the build tree)<br />
# it iterates over the generators listed in that file's CPACK_GENERATOR list variable (unless told to use just a specific one via -G on the command line...), then for each generator it:<br />
## sets CPACK_GENERATOR to the one currently being iterated over. This is the key: For each generator listed in CPACK_GENERATOR in CPackConfig.cmake, cpack will '''reset''' CPACK_GENERATOR internally to '''the one currently being used''' and then include the CPACK_PROJECT_CONFIG_FILE.<br />
## includes the CPACK_PROJECT_CONFIG_FILE<br />
## produces the package for that generator<br />
<br />
==Archive Generators==<br />
<br />
The archive generators are a family of CPack generators derived from the same base class generator. These generators use the [http://code.google.com/p/libarchive/ libarchive] library to produce various archive file formats. These generators share common properties which are explained in this section. Specific features are explained in sections corresponding to the specific generator.<br />
<br />
Please note that one might want to try to avoid packaging symlinks within .tgz, .tbz2 or similar archives, the reason being that libarchive converts them to hard links, and, to add insult to injury, it then even ''clips'' (read: '''corrupts''') even moderately long paths, causing tar '''extraction failure''' (observed in CMake 2.6.4 Linux, TODO list experience with newer versions).<br />
<br />
===TGZ===<br />
<br />
Tar GZip compressed packages.<br />
<br />
===STGZ===<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
===TBZ2===<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package. <br />
<br />
===TZ===<br />
<br />
Tar UNIX compress compressed packages. <br />
<br />
===ZIP===<br />
<br />
ZIP compressed packages. CMake 2.4.x required zip, WinZip or 7Zip for creating the package. CMake 2.8.x built-in libarchive support does not need external programs in order to build ZIP.<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package. See the [[CMake:CPackNSISAdvancedTips|Advanced Tips]] for details on customizing an NSIS script through CPack.<br />
<br />
=== NSIS Generator Specifics settings ===<br />
<br />
{|<br />
|- bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_NSIS_MUI_ICON || The icon file (.ico) for the generated install program. Both this and CPACK_NSIS_MUI_UNIICON need to set for this to have any effect. || installer.ico<br />
|-<br />
| CPACK_NSIS_MUI_UNIICON || The icon file (.ico) for the generated uninstall program. Both this and CPACK_NSIS_MUI_ICON need to set for this to have any effect. || uninstaller.ico<br />
|-<br />
| CPACK_PACKAGE_ICON || A branding image that will be displayed on the top bar inside the installer. || installer.bmp<br />
|-<br />
| CPACK_NSIS_EXTRA_INSTALL_COMMANDS || Extra NSIS commands that will be added to the install Section. || ExecWait '\\\"$INSTDIR\\\\vcredist_x86.exe\\\" /q:a'<br />
|-<br />
| CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS || Extra NSIS commands that will be added to the uninstall Section. || <br />
|-<br />
| CPACK_NSIS_COMPRESSOR || The arguments that will be passed to the NSIS SetCompressor command. || /SOLID lzma<br />
|-<br />
| CPACK_NSIS_MODIFY_PATH || If this is set to "ON", then an extra page will appear in the installer that will allow the user to choose whether the program directory should be added to the system PATH variable. It will also display a checkbox allowing to install desktop shorcut icons configured with CPACK_CREATE_DESKTOP_LINKS. || ON<br />
|-<br />
| CPACK_NSIS_DISPLAY_NAME || Undocumented. || "${CPACK_PACKAGE_INSTALL_DIRECTORY} My Famous Project"<br />
|-<br />
| CPACK_NSIS_INSTALLED_ICON_NAME || Set the icon used for the Windows "Add or Remove Programs" tool. || "bin\\\\MyExecutable.exe"<br />
|-<br />
| CPACK_NSIS_HELP_LINK || Adds link to registry. URI. || "http:\\\\\\\\www.my-project-home-page.org"<br />
|-<br />
| CPACK_NSIS_URL_INFO_ABOUT || Adds link to registry and the vendor in add/remove programs' "Click here for support information" in program entry links here. || "http:\\\\\\\\www.my-personal-home-page.com"<br />
|-<br />
| CPACK_NSIS_CONTACT || Adds link to add/remove programs' "Click here for support information" in program entry. || "me@my-personal-home-page.com"<br />
|-<br />
| CPACK_NSIS_CREATE_ICONS_EXTRA || Additional NSIS commands for creating start menu shortcuts. || set(CPACK_NSIS_CREATE_ICONS "CreateShortCut '\$SMPROGRAMS\\\\$STARTMENU_FOLDER\\\\${PROJECT_NAME}.lnk' '\$INSTDIR\\\\${PROJECT_NAME}.exe'")<br />
|-<br />
| CPACK_NSIS_DELETE_ICONS_EXTRA || Undocumented. Possibly: Additional NSIS commands to uninstall start menu shortcuts. ||<br />
|-<br />
| CPACK_NSIS_MENU_LINKS || Used to override the Start Menu links. || "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/CMakeSetup.html" "CMakeSetup Help"<br />
|-<br />
| CPACK_NSIS_EXECUTABLES_DIRECTORY || Override the default path ("bin/") where NSIS will find executables, used by CPACK_NSIS_MUI_FINISHPAGE_RUN || set(CPACK_NSIS_EXECUTABLES_DIRECTORY ".")<br />
|-<br />
| CPACK_NSIS_MUI_FINISHPAGE_RUN || If used, will make it possible for user to choose (on an additional page, displayed at the end of the installation) to run intalled program. Should point to program name to run, seemingly without any sub-directories of the installation directory in case program installed in such sub-directories (but please check generated NSIS script if you can't make it work). || "MyExecutable.exe"<br />
|-<br />
|}<br />
<br />
==DragNDrop (OSX only)==<br />
<br />
Mac OSX Drag and Drop generator. This generator simply creates a .DMG disk image file that is populated by install() commands, as if it were the install prefix. You would use this generator by creating an executable with the '''MACOSX_BUNDLE''' option, then using '''SOURCE PROPERTY MACOSX_PACKAGE_LOCATION''' and '''TARGET PROPERTY MACOSX_BUNDLE_PLIST''' to put other files inside the bundle. Make sure to install your executables to the root install prefix (use the "DESTINATION ." argument to install()) so that they are visible to the user when they open the DMG. <br />
<br />
It seems to be impossible to put multiple executables inside a bundle using this generator; for that you should use the Bundle generator. However, you can include shared libraries by using '''fixup_bundle()''' from BundleUtilities.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
Some of the variables that you can use to customize the Package Maker generated package:<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
! Variable Name || Description || Default value<br />
|-<br />
| CPACK_PREFLIGHT_SCRIPT || This script is launched just after the user clicked on the "Install" button. || - <br />
|-<br />
| CPACK_POSTFLIGHT_SCRIPT || This script is launched after the postinstall / postupgrade script or when the package has been || -<br />
|-<br />
| CPACK_POSTUPGRADE_SCRIPT || This script is launched after the files in the package have been installed. (Isn't an option for a postinstall script missing? According to Apple documentation, postinstall is executed the first time a package is installed and postupgrade all subsequent times) || -<br />
|-<br />
| CPACK_OSX_PACKAGE_VERSION || Set to the minimum OS X version you support. Choices are currently 10.3, 10.4 and 10.5 || 10.3, unless you specified features that require a higher OS X version (CPACK_DOWNLOAD_SITE, CPACK_COMPONENTS_ALL)<br />
|}<br />
<br />
This is a useful site that describes where the scripts get executed and what the arguments to the scripts are. See section "What about scripts?". http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html . In summary the arguments correspond to $0 Script path, $1 Package path, $2 Target location, and $3 Target Volume.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged using the bundle-generator! Specifying MACOSX_BUNDLE creates a separate bundle for each individual executable at build-time; the structure of these bundles becomes redundant when the bundle generator consolidates multiple executables into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. This file should be present in the source or build tree after a build; CPackBundle will copy it into the correct place in the bundle. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Generate a default Info.plist file if CPACK_BUNDLE_PLIST is not defined.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
* Provide an option or alternative to CPACK_BUNDLE_STARTUP_COMMAND that simply executes one of the files installed in the bundle. Presumably, this should be a symlink to a binary or script.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package. This file is created automatically using the following variables, some of which are mandatory and some are optional. <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
<pre><br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
</pre><br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if CPACK_DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set CPACK_DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set CPACK_DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: CPACK_DEBIAN_PACKAGE_SUGGESTS<br />
<br />
'''Control Extra'''<br />
* Additional control files (optional)<br />
* In order to perform pre-, or post-install configuration, certain files can be provided in the DEBIAN/ folder in the debian package (postinst, preinst, postrm, prerm)<br />
* You should set: CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA <br />
* E.g.<br />
<pre><br />
set( CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CMAKE_CURRENT_SOURCE_DIR}/CMake/debian/postinst;${CMAKE_CURRENT_SOURCE_DIR}/CMake/debian/prerm;" )<br />
</pre><br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
<pre><br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
</pre><br />
<br />
===Debian Generator specific settings===<br />
{|<br />
|- bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_MAINTAINER || The maintenainer informations || Firstname Lastname <email@example.com><br />
|-<br />
| CPACK_PACKAGE_DESCRIPTION_SUMMARY || Package short description || Here is my short description<br />
|-<br />
| CPACK_PACKAGE_DESCRIPTION || Package description || Here is my long description<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_DEPENDS || Package dependencies (use dpkg -s <packagename> to retrieve version) || libc6 (>= 2.7-18)<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA || This variable allow advanced user to add custom script to the control.tar.gz (inside the .deb archive) || ${CMAKE_CURRENT_SOURCE_DIR}/postinst<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_SECTION || Package section (see http://packages.debian.org/stable/) || Network<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_VERSION || Package version || ${CPACK_PACKAGE_VERSION}+lenny1<br />
|-<br />
|}<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
The CPack RPM generator supports [[CMake:Component_Install_With_CPack|CPack Component installation]]. You can find details about the implementation [[http://public.kitware.com/Bug/view.php?id=7645 here]].<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is similar to other CPack generators. Its execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
Since CMake/CPack 2.8.0, a detailed description of how to use the CPACK_RPM_xxxx is available in this article or from the CMake command line:<br />
<br />
<pre><br />
cmake --help-module CPackRPM<br />
</pre><br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<pre><br />
cd build_dir<br />
make package<br />
</pre><br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
<pre><br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
</pre><br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
=== CPack RPM generators specific settings ===<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
! Variable Name || Description || Default value<br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group (see /usr/share/doc/rpm-*/GROUPS ) || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package vendor || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_PACKAGE_REQUIRES'' || May be used to set RPM dependencies. see [[http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html RPM dependencies specification]]) for precise syntax. Note that you must enclose the complete requires string between quotes, for example:<br /> set(CPACK_RPM_PACKAGE_REQUIRES "python >= 2.5.0, cmake >= 2.8")|| - <br />
|-<br />
| ''CPACK_RPM_PACKAGE_PROVIDES'' || May be used to set the virtual packages provided by the RPM. It is somewhat complimentary to CPACK_RPM_PACKAGE_REQUIRES, but note that you do not need to list things like libraries, etc. here, since rpmbuild will figure that out by itself when generating the RPM. Most packages leave this blank. NOTE: This variable was added in cmake 2.8.1 (see [[http://public.kitware.com/Bug/view.php?id=9584 Bug9584]]).|| - <br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435 Bug7435]]). This is '''not to be confused''' with .spec %post section (the action specified here is being invoked at ''rpmbuild'' time, not ''post-install-package'' time at user side) || -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679]]|| -<br />
|-<br />
| ''CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE'' || May be used to generate a '''template''' for a user provided spec file. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679]]|| -<br />
|-<br />
| ''CPACK_RPM_<POST/PRE>_<UN>INSTALL_SCRIPT_FILE'' || The content of the specified files will be embedded in the RPM spec file in the appropriate sections. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=8988 Bug8988]] || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM currently pending bugs/features ===<br />
Here the may-be-incomplete lists of pendings bugs/features request<br />
linked to CPackRPM:<br />
<br />
* Support for COMPONENT [[http://public.kitware.com/Bug/view.php?id=7645 Bug7645-PreliminaryPatchUnderway]] this one will need more work since it depends on [[http://public.kitware.com/Bug/view.php?id=9900 Bug9900]]<br />
* RPM Post/Pre (un)install script support [[http://public.kitware.com/Bug/view.php?id=8988 Bug8988-Fixed since 2.8.1]]<br />
* Builtin documentation with ''cmake --help-module CPackRPM'' [[http://public.kitware.com/Bug/view.php?id=9029 Bug9029-Fixed since 2.8.0]]<br />
* RPM 4.6.x support <br />
** Fedora Core 10 fix, [[http://public.kitware.com/Bug/view.php?id=8967 Bug8967-Fixed since 2.8.1]]<br />
** Mandriva 2009.1 fix, [[http://public.kitware.com/Bug/view.php?id=9031 Bug9031-Fixed since 2.8.1]]<br />
* Support USER supplied "Provides" [[http://public.kitware.com/Bug/view.php?id=9584 Bug9584-Fixed since 2.8.1]]<br />
* Related bugs<br />
** Do not include include directories in %file section [[http://public.kitware.com/Bug/view.php?id=9654 Bug9654-Fixed since 2.8.1]]<br />
** Symlink not packaged [[http://public.kitware.com/Bug/view.php?id=9927 Bug9927-Fixed since 2.8.1]]<br />
* Support of USER specified spec file [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679-Fixed since 2.8.1]]<br />
* RPM 4.7.1 / Fedora 11 Issue, [[http://public.kitware.com/Bug/view.php?id=9872 Bug9872-Fixed since 2.8.1]]<br />
* RPM Generator, spaces in CPACK_PACKAGE_NAME cause error [[http://public.kitware.com/Bug/view.php?id=9932 Bug9932-Unfixable]]<br />
<br />
=== CPack RPM Historical Notes ===<br />
<br />
CPackRPM included along with CMake 2.8.1 is provided many new features and bug fixes<br />
--[[User:Erk|Erk]] 14:33, 20 February 2010 (UTC)<br />
<br />
The binary CPackRPM generator should now work for many RPM based distribution and rpmbuild version.<br />
[[User:Erk|Erk]] was granted CVS commit right for CPackRPM and he's maintaining and improving it as long<br />
as spare time is available --[[User:Erk|Erk]] 14:30, 20 February 2010 (UTC)<br />
<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The built-in CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=62626CMake:CPackPackageGenerators2018-04-24T18:58:18Z<p>Brad.king: /* PackageMaker (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
CPack may generate several kind of package on behalf of various ''CPack Generators''. All generators share common properties explained below. Some if not all generators do have specific features or restriction which are explained in specific sections.<br />
<br />
Since CPack 2.8.8, CPack has builtin documentation just like CMake so that one can use:<br />
<br />
<pre><br />
cpack --help-variable-list<br />
cpack --help-variable <VARNAME><br />
cpack --help-command-list<br />
cpack --help-command <CMDNAME><br />
...<br />
cpack --help<br />
</pre><br />
<br />
in order to get specific documentation. This [http://www.cmake.org/Wiki/CMake_builtin_documentation_handling builtin documentation] should be the most up to date documentation for CPack.<br />
The current Wiki is a convenient place to find informations but may not be as up to date as the builtin doc.<br />
<br />
If ever you find undocumented variable and/or innaccurate documentation please file a [http://public.kitware.com/Bug/main_page.php bug report].<br />
The main part of CPack variable or command documentation may be found in CPack<GEN>.cmake file in the CMake source, the documentation is extracted from those files automatically and dynamically by CPack, so you can submit a documentation patch using one of those files.<br />
<br />
== Overall usage (common to all generators) ==<br />
<br />
Information about CPACK_xxx variables used for CPack configuration<br />
may be found there: [http://www.cmake.org/Wiki/CMake:CPackConfiguration CPackConfiguration]<br />
<br />
The CPACK_GENERATOR variable has different meanings in different contexts. In your CMakeLists.txt file, CPACK_GENERATOR is a '''list of generators''': when run with no other arguments, CPack will iterate over that list and produce one package for each generator. In a CPACK_PROJECT_CONFIG_FILE, though, CPACK_GENERATOR is a '''string naming a single generator'''. If you need per-cpack-generator logic to control '''other''' cpack settings, then you need a CPACK_PROJECT_CONFIG_FILE. For example it may be used to switch on/off [http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior component packaging] for a specific generator.<br />
<br />
The CMake source tree itself contains a CPACK_PROJECT_CONFIG_FILE. See the top level file [http://cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeCPackOptions.cmake.in;hb=HEAD CMakeCPackOptions.cmake.in] for an example.<br />
<br />
If set, the CPACK_PROJECT_CONFIG_FILE is included automatically on a per-generator basis. It only needs to contain overrides.<br />
<br />
Here's how it works:<br />
# cpack runs<br />
# it includes CPackConfig.cmake (usually found in the build tree)<br />
# it iterates over the generators listed in that file's CPACK_GENERATOR list variable (unless told to use just a specific one via -G on the command line...), then for each generator it:<br />
## sets CPACK_GENERATOR to the one currently being iterated over. This is the key: For each generator listed in CPACK_GENERATOR in CPackConfig.cmake, cpack will '''reset''' CPACK_GENERATOR internally to '''the one currently being used''' and then include the CPACK_PROJECT_CONFIG_FILE.<br />
## includes the CPACK_PROJECT_CONFIG_FILE<br />
## produces the package for that generator<br />
<br />
==Archive Generators==<br />
<br />
The archive generators are a family of CPack generators derived from the same base class generator. These generators use the [http://code.google.com/p/libarchive/ libarchive] library to produce various archive file formats. These generators share common properties which are explained in this section. Specific features are explained in sections corresponding to the specific generator.<br />
<br />
Please note that one might want to try to avoid packaging symlinks within .tgz, .tbz2 or similar archives, the reason being that libarchive converts them to hard links, and, to add insult to injury, it then even ''clips'' (read: '''corrupts''') even moderately long paths, causing tar '''extraction failure''' (observed in CMake 2.6.4 Linux, TODO list experience with newer versions).<br />
<br />
===TGZ===<br />
<br />
Tar GZip compressed packages.<br />
<br />
===STGZ===<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
===TBZ2===<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package. <br />
<br />
===TZ===<br />
<br />
Tar UNIX compress compressed packages. <br />
<br />
===ZIP===<br />
<br />
ZIP compressed packages. CMake 2.4.x required zip, WinZip or 7Zip for creating the package. CMake 2.8.x built-in libarchive support does not need external programs in order to build ZIP.<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package. See the [[CMake:CPackNSISAdvancedTips|Advanced Tips]] for details on customizing an NSIS script through CPack.<br />
<br />
=== NSIS Generator Specifics settings ===<br />
<br />
{|<br />
|- bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_NSIS_MUI_ICON || The icon file (.ico) for the generated install program. Both this and CPACK_NSIS_MUI_UNIICON need to set for this to have any effect. || installer.ico<br />
|-<br />
| CPACK_NSIS_MUI_UNIICON || The icon file (.ico) for the generated uninstall program. Both this and CPACK_NSIS_MUI_ICON need to set for this to have any effect. || uninstaller.ico<br />
|-<br />
| CPACK_PACKAGE_ICON || A branding image that will be displayed on the top bar inside the installer. || installer.bmp<br />
|-<br />
| CPACK_NSIS_EXTRA_INSTALL_COMMANDS || Extra NSIS commands that will be added to the install Section. || ExecWait '\\\"$INSTDIR\\\\vcredist_x86.exe\\\" /q:a'<br />
|-<br />
| CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS || Extra NSIS commands that will be added to the uninstall Section. || <br />
|-<br />
| CPACK_NSIS_COMPRESSOR || The arguments that will be passed to the NSIS SetCompressor command. || /SOLID lzma<br />
|-<br />
| CPACK_NSIS_MODIFY_PATH || If this is set to "ON", then an extra page will appear in the installer that will allow the user to choose whether the program directory should be added to the system PATH variable. It will also display a checkbox allowing to install desktop shorcut icons configured with CPACK_CREATE_DESKTOP_LINKS. || ON<br />
|-<br />
| CPACK_NSIS_DISPLAY_NAME || Undocumented. || "${CPACK_PACKAGE_INSTALL_DIRECTORY} My Famous Project"<br />
|-<br />
| CPACK_NSIS_INSTALLED_ICON_NAME || Set the icon used for the Windows "Add or Remove Programs" tool. || "bin\\\\MyExecutable.exe"<br />
|-<br />
| CPACK_NSIS_HELP_LINK || Adds link to registry. URI. || "http:\\\\\\\\www.my-project-home-page.org"<br />
|-<br />
| CPACK_NSIS_URL_INFO_ABOUT || Adds link to registry and the vendor in add/remove programs' "Click here for support information" in program entry links here. || "http:\\\\\\\\www.my-personal-home-page.com"<br />
|-<br />
| CPACK_NSIS_CONTACT || Adds link to add/remove programs' "Click here for support information" in program entry. || "me@my-personal-home-page.com"<br />
|-<br />
| CPACK_NSIS_CREATE_ICONS_EXTRA || Additional NSIS commands for creating start menu shortcuts. || set(CPACK_NSIS_CREATE_ICONS "CreateShortCut '\$SMPROGRAMS\\\\$STARTMENU_FOLDER\\\\${PROJECT_NAME}.lnk' '\$INSTDIR\\\\${PROJECT_NAME}.exe'")<br />
|-<br />
| CPACK_NSIS_DELETE_ICONS_EXTRA || Undocumented. Possibly: Additional NSIS commands to uninstall start menu shortcuts. ||<br />
|-<br />
| CPACK_NSIS_MENU_LINKS || Used to override the Start Menu links. || "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/CMakeSetup.html" "CMakeSetup Help"<br />
|-<br />
| CPACK_NSIS_EXECUTABLES_DIRECTORY || Override the default path ("bin/") where NSIS will find executables, used by CPACK_NSIS_MUI_FINISHPAGE_RUN || set(CPACK_NSIS_EXECUTABLES_DIRECTORY ".")<br />
|-<br />
| CPACK_NSIS_MUI_FINISHPAGE_RUN || If used, will make it possible for user to choose (on an additional page, displayed at the end of the installation) to run intalled program. Should point to program name to run, seemingly without any sub-directories of the installation directory in case program installed in such sub-directories (but please check generated NSIS script if you can't make it work). || "MyExecutable.exe"<br />
|-<br />
|}<br />
<br />
==DragNDrop (OSX only)==<br />
<br />
Mac OSX Drag and Drop generator. This generator simply creates a .DMG disk image file that is populated by install() commands, as if it were the install prefix. You would use this generator by creating an executable with the '''MACOSX_BUNDLE''' option, then using '''SOURCE PROPERTY MACOSX_PACKAGE_LOCATION''' and '''TARGET PROPERTY MACOSX_BUNDLE_PLIST''' to put other files inside the bundle. Make sure to install your executables to the root install prefix (use the "DESTINATION ." argument to install()) so that they are visible to the user when they open the DMG. <br />
<br />
It seems to be impossible to put multiple executables inside a bundle using this generator; for that you should use the Bundle generator. However, you can include shared libraries by using '''fixup_bundle()''' from BundleUtilities.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
Some of the variables that you can use to customize the Package Maker generated package:<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
! Variable Name || Description || Default value<br />
|-<br />
| CPACK_PREFLIGHT_SCRIPT || This script is launched just after the user clicked on the "Install" button. || - <br />
|-<br />
| CPACK_POSTFLIGHT_SCRIPT || This script is launched after the postinstall / postupgrade script or when the package has been || -<br />
|-<br />
| CPACK_POSTUPGRADE_SCRIPT || This script is launched after the files in the package have been installed. (Isn't an option for a postinstall script missing? According to Apple documentation, postinstall is executed the first time a package is installed and postupgrade all subsequent times) || -<br />
|-<br />
| CPACK_OSX_PACKAGE_VERSION || Set to the minimum OS X version you support. Choices are currently 10.3, 10.4 and 10.5 || 10.3, unless you specified features that require a higher OS X version (CPACK_DOWNLOAD_SITE, CPACK_COMPONENTS_ALL)<br />
|}<br />
<br />
This is a useful site that describes where the scripts get executed and what the arguments to the scripts are. See section "What about scripts?". http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html . In summary the arguments correspond to $0 Script path, $1 Package path, $2 Target location, and $3 Target Volume.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged using the bundle-generator! Specifying MACOSX_BUNDLE creates a separate bundle for each individual executable at build-time; the structure of these bundles becomes redundant when the bundle generator consolidates multiple executables into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. This file should be present in the source or build tree after a build; CPackBundle will copy it into the correct place in the bundle. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Generate a default Info.plist file if CPACK_BUNDLE_PLIST is not defined.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
* Provide an option or alternative to CPACK_BUNDLE_STARTUP_COMMAND that simply executes one of the files installed in the bundle. Presumably, this should be a symlink to a binary or script.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package. This file is created automatically using the following variables, some of which are mandatory and some are optional. <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
<pre><br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
</pre><br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if CPACK_DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set CPACK_DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set CPACK_DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: CPACK_DEBIAN_PACKAGE_SUGGESTS<br />
<br />
'''Control Extra'''<br />
* Additional control files (optional)<br />
* In order to perform pre-, or post-install configuration, certain files can be provided in the DEBIAN/ folder in the debian package (postinst, preinst, postrm, prerm)<br />
* You should set: CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA <br />
* E.g.<br />
<pre><br />
set( CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CMAKE_CURRENT_SOURCE_DIR}/CMake/debian/postinst;${CMAKE_CURRENT_SOURCE_DIR}/CMake/debian/prerm;" )<br />
</pre><br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
<pre><br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
</pre><br />
<br />
===Debian Generator specific settings===<br />
{|<br />
|- bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_MAINTAINER || The maintenainer informations || Firstname Lastname <email@example.com><br />
|-<br />
| CPACK_PACKAGE_DESCRIPTION_SUMMARY || Package short description || Here is my short description<br />
|-<br />
| CPACK_PACKAGE_DESCRIPTION || Package description || Here is my long description<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_DEPENDS || Package dependencies (use dpkg -s <packagename> to retrieve version) || libc6 (>= 2.7-18)<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA || This variable allow advanced user to add custom script to the control.tar.gz (inside the .deb archive) || ${CMAKE_CURRENT_SOURCE_DIR}/postinst<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_SECTION || Package section (see http://packages.debian.org/stable/) || Network<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_VERSION || Package version || ${CPACK_PACKAGE_VERSION}+lenny1<br />
|-<br />
|}<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
The CPack RPM generator supports [[CMake:Component_Install_With_CPack|CPack Component installation]]. You can find details about the implementation [[http://public.kitware.com/Bug/view.php?id=7645 here]].<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is similar to other CPack generators. Its execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
Since CMake/CPack 2.8.0, a detailed description of how to use the CPACK_RPM_xxxx is available in this article or from the CMake command line:<br />
<br />
<pre><br />
cmake --help-module CPackRPM<br />
</pre><br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<pre><br />
cd build_dir<br />
make package<br />
</pre><br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
<pre><br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
</pre><br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
=== CPack RPM generators specific settings ===<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group (see /usr/share/doc/rpm-*/GROUPS ) || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package vendor || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_PACKAGE_REQUIRES'' || May be used to set RPM dependencies. see [[http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html RPM dependencies specification]]) for precise syntax. Note that you must enclose the complete requires string between quotes, for example:<br /> set(CPACK_RPM_PACKAGE_REQUIRES "python >= 2.5.0, cmake >= 2.8")|| - <br />
|-<br />
| ''CPACK_RPM_PACKAGE_PROVIDES'' || May be used to set the virtual packages provided by the RPM. It is somewhat complimentary to CPACK_RPM_PACKAGE_REQUIRES, but note that you do not need to list things like libraries, etc. here, since rpmbuild will figure that out by itself when generating the RPM. Most packages leave this blank. NOTE: This variable was added in cmake 2.8.1 (see [[http://public.kitware.com/Bug/view.php?id=9584 Bug9584]]).|| - <br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435 Bug7435]]). This is '''not to be confused''' with .spec %post section (the action specified here is being invoked at ''rpmbuild'' time, not ''post-install-package'' time at user side) || -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679]]|| -<br />
|-<br />
| ''CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE'' || May be used to generate a '''template''' for a user provided spec file. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679]]|| -<br />
|-<br />
| ''CPACK_RPM_<POST/PRE>_<UN>INSTALL_SCRIPT_FILE'' || The content of the specified files will be embedded in the RPM spec file in the appropriate sections. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=8988 Bug8988]] || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM currently pending bugs/features ===<br />
Here the may-be-incomplete lists of pendings bugs/features request<br />
linked to CPackRPM:<br />
<br />
* Support for COMPONENT [[http://public.kitware.com/Bug/view.php?id=7645 Bug7645-PreliminaryPatchUnderway]] this one will need more work since it depends on [[http://public.kitware.com/Bug/view.php?id=9900 Bug9900]]<br />
* RPM Post/Pre (un)install script support [[http://public.kitware.com/Bug/view.php?id=8988 Bug8988-Fixed since 2.8.1]]<br />
* Builtin documentation with ''cmake --help-module CPackRPM'' [[http://public.kitware.com/Bug/view.php?id=9029 Bug9029-Fixed since 2.8.0]]<br />
* RPM 4.6.x support <br />
** Fedora Core 10 fix, [[http://public.kitware.com/Bug/view.php?id=8967 Bug8967-Fixed since 2.8.1]]<br />
** Mandriva 2009.1 fix, [[http://public.kitware.com/Bug/view.php?id=9031 Bug9031-Fixed since 2.8.1]]<br />
* Support USER supplied "Provides" [[http://public.kitware.com/Bug/view.php?id=9584 Bug9584-Fixed since 2.8.1]]<br />
* Related bugs<br />
** Do not include include directories in %file section [[http://public.kitware.com/Bug/view.php?id=9654 Bug9654-Fixed since 2.8.1]]<br />
** Symlink not packaged [[http://public.kitware.com/Bug/view.php?id=9927 Bug9927-Fixed since 2.8.1]]<br />
* Support of USER specified spec file [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679-Fixed since 2.8.1]]<br />
* RPM 4.7.1 / Fedora 11 Issue, [[http://public.kitware.com/Bug/view.php?id=9872 Bug9872-Fixed since 2.8.1]]<br />
* RPM Generator, spaces in CPACK_PACKAGE_NAME cause error [[http://public.kitware.com/Bug/view.php?id=9932 Bug9932-Unfixable]]<br />
<br />
=== CPack RPM Historical Notes ===<br />
<br />
CPackRPM included along with CMake 2.8.1 is provided many new features and bug fixes<br />
--[[User:Erk|Erk]] 14:33, 20 February 2010 (UTC)<br />
<br />
The binary CPackRPM generator should now work for many RPM based distribution and rpmbuild version.<br />
[[User:Erk|Erk]] was granted CVS commit right for CPackRPM and he's maintaining and improving it as long<br />
as spare time is available --[[User:Erk|Erk]] 14:30, 20 February 2010 (UTC)<br />
<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The built-in CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake:CPackPackageGenerators&diff=62625CMake:CPackPackageGenerators2018-04-24T18:57:28Z<p>Brad.king: /* PackageMaker (OSX only) */</p>
<hr />
<div>=CPack Package Generators=<br />
<br />
CPack may generate several kind of package on behalf of various ''CPack Generators''. All generators share common properties explained below. Some if not all generators do have specific features or restriction which are explained in specific sections.<br />
<br />
Since CPack 2.8.8, CPack has builtin documentation just like CMake so that one can use:<br />
<br />
<pre><br />
cpack --help-variable-list<br />
cpack --help-variable <VARNAME><br />
cpack --help-command-list<br />
cpack --help-command <CMDNAME><br />
...<br />
cpack --help<br />
</pre><br />
<br />
in order to get specific documentation. This [http://www.cmake.org/Wiki/CMake_builtin_documentation_handling builtin documentation] should be the most up to date documentation for CPack.<br />
The current Wiki is a convenient place to find informations but may not be as up to date as the builtin doc.<br />
<br />
If ever you find undocumented variable and/or innaccurate documentation please file a [http://public.kitware.com/Bug/main_page.php bug report].<br />
The main part of CPack variable or command documentation may be found in CPack<GEN>.cmake file in the CMake source, the documentation is extracted from those files automatically and dynamically by CPack, so you can submit a documentation patch using one of those files.<br />
<br />
== Overall usage (common to all generators) ==<br />
<br />
Information about CPACK_xxx variables used for CPack configuration<br />
may be found there: [http://www.cmake.org/Wiki/CMake:CPackConfiguration CPackConfiguration]<br />
<br />
The CPACK_GENERATOR variable has different meanings in different contexts. In your CMakeLists.txt file, CPACK_GENERATOR is a '''list of generators''': when run with no other arguments, CPack will iterate over that list and produce one package for each generator. In a CPACK_PROJECT_CONFIG_FILE, though, CPACK_GENERATOR is a '''string naming a single generator'''. If you need per-cpack-generator logic to control '''other''' cpack settings, then you need a CPACK_PROJECT_CONFIG_FILE. For example it may be used to switch on/off [http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#CPack_Generator_specific_behavior component packaging] for a specific generator.<br />
<br />
The CMake source tree itself contains a CPACK_PROJECT_CONFIG_FILE. See the top level file [http://cmake.org/gitweb?p=cmake.git;a=blob;f=CMakeCPackOptions.cmake.in;hb=HEAD CMakeCPackOptions.cmake.in] for an example.<br />
<br />
If set, the CPACK_PROJECT_CONFIG_FILE is included automatically on a per-generator basis. It only needs to contain overrides.<br />
<br />
Here's how it works:<br />
# cpack runs<br />
# it includes CPackConfig.cmake (usually found in the build tree)<br />
# it iterates over the generators listed in that file's CPACK_GENERATOR list variable (unless told to use just a specific one via -G on the command line...), then for each generator it:<br />
## sets CPACK_GENERATOR to the one currently being iterated over. This is the key: For each generator listed in CPACK_GENERATOR in CPackConfig.cmake, cpack will '''reset''' CPACK_GENERATOR internally to '''the one currently being used''' and then include the CPACK_PROJECT_CONFIG_FILE.<br />
## includes the CPACK_PROJECT_CONFIG_FILE<br />
## produces the package for that generator<br />
<br />
==Archive Generators==<br />
<br />
The archive generators are a family of CPack generators derived from the same base class generator. These generators use the [http://code.google.com/p/libarchive/ libarchive] library to produce various archive file formats. These generators share common properties which are explained in this section. Specific features are explained in sections corresponding to the specific generator.<br />
<br />
Please note that one might want to try to avoid packaging symlinks within .tgz, .tbz2 or similar archives, the reason being that libarchive converts them to hard links, and, to add insult to injury, it then even ''clips'' (read: '''corrupts''') even moderately long paths, causing tar '''extraction failure''' (observed in CMake 2.6.4 Linux, TODO list experience with newer versions).<br />
<br />
===TGZ===<br />
<br />
Tar GZip compressed packages.<br />
<br />
===STGZ===<br />
<br />
Self extracting Tar GZip compressed packages (needs /bin/sh, tar, gunzip and tail for extracting).<br />
<br />
===TBZ2===<br />
<br />
Tar BZip2 compressed packages. Requires bzip2 for creating the package. <br />
<br />
===TZ===<br />
<br />
Tar UNIX compress compressed packages. <br />
<br />
===ZIP===<br />
<br />
ZIP compressed packages. CMake 2.4.x required zip, WinZip or 7Zip for creating the package. CMake 2.8.x built-in libarchive support does not need external programs in order to build ZIP.<br />
<br />
==NSIS==<br />
<br />
Nullsoft Installer. Requires [http://nsis.sourceforge.net/ NSIS] for creating the package. See the [[CMake:CPackNSISAdvancedTips|Advanced Tips]] for details on customizing an NSIS script through CPack.<br />
<br />
=== NSIS Generator Specifics settings ===<br />
<br />
{|<br />
|- bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_NSIS_MUI_ICON || The icon file (.ico) for the generated install program. Both this and CPACK_NSIS_MUI_UNIICON need to set for this to have any effect. || installer.ico<br />
|-<br />
| CPACK_NSIS_MUI_UNIICON || The icon file (.ico) for the generated uninstall program. Both this and CPACK_NSIS_MUI_ICON need to set for this to have any effect. || uninstaller.ico<br />
|-<br />
| CPACK_PACKAGE_ICON || A branding image that will be displayed on the top bar inside the installer. || installer.bmp<br />
|-<br />
| CPACK_NSIS_EXTRA_INSTALL_COMMANDS || Extra NSIS commands that will be added to the install Section. || ExecWait '\\\"$INSTDIR\\\\vcredist_x86.exe\\\" /q:a'<br />
|-<br />
| CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS || Extra NSIS commands that will be added to the uninstall Section. || <br />
|-<br />
| CPACK_NSIS_COMPRESSOR || The arguments that will be passed to the NSIS SetCompressor command. || /SOLID lzma<br />
|-<br />
| CPACK_NSIS_MODIFY_PATH || If this is set to "ON", then an extra page will appear in the installer that will allow the user to choose whether the program directory should be added to the system PATH variable. It will also display a checkbox allowing to install desktop shorcut icons configured with CPACK_CREATE_DESKTOP_LINKS. || ON<br />
|-<br />
| CPACK_NSIS_DISPLAY_NAME || Undocumented. || "${CPACK_PACKAGE_INSTALL_DIRECTORY} My Famous Project"<br />
|-<br />
| CPACK_NSIS_INSTALLED_ICON_NAME || Set the icon used for the Windows "Add or Remove Programs" tool. || "bin\\\\MyExecutable.exe"<br />
|-<br />
| CPACK_NSIS_HELP_LINK || Adds link to registry. URI. || "http:\\\\\\\\www.my-project-home-page.org"<br />
|-<br />
| CPACK_NSIS_URL_INFO_ABOUT || Adds link to registry and the vendor in add/remove programs' "Click here for support information" in program entry links here. || "http:\\\\\\\\www.my-personal-home-page.com"<br />
|-<br />
| CPACK_NSIS_CONTACT || Adds link to add/remove programs' "Click here for support information" in program entry. || "me@my-personal-home-page.com"<br />
|-<br />
| CPACK_NSIS_CREATE_ICONS_EXTRA || Additional NSIS commands for creating start menu shortcuts. || set(CPACK_NSIS_CREATE_ICONS "CreateShortCut '\$SMPROGRAMS\\\\$STARTMENU_FOLDER\\\\${PROJECT_NAME}.lnk' '\$INSTDIR\\\\${PROJECT_NAME}.exe'")<br />
|-<br />
| CPACK_NSIS_DELETE_ICONS_EXTRA || Undocumented. Possibly: Additional NSIS commands to uninstall start menu shortcuts. ||<br />
|-<br />
| CPACK_NSIS_MENU_LINKS || Used to override the Start Menu links. || "doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/CMakeSetup.html" "CMakeSetup Help"<br />
|-<br />
| CPACK_NSIS_EXECUTABLES_DIRECTORY || Override the default path ("bin/") where NSIS will find executables, used by CPACK_NSIS_MUI_FINISHPAGE_RUN || set(CPACK_NSIS_EXECUTABLES_DIRECTORY ".")<br />
|-<br />
| CPACK_NSIS_MUI_FINISHPAGE_RUN || If used, will make it possible for user to choose (on an additional page, displayed at the end of the installation) to run intalled program. Should point to program name to run, seemingly without any sub-directories of the installation directory in case program installed in such sub-directories (but please check generated NSIS script if you can't make it work). || "MyExecutable.exe"<br />
|-<br />
|}<br />
<br />
==DragNDrop (OSX only)==<br />
<br />
Mac OSX Drag and Drop generator. This generator simply creates a .DMG disk image file that is populated by install() commands, as if it were the install prefix. You would use this generator by creating an executable with the '''MACOSX_BUNDLE''' option, then using '''SOURCE PROPERTY MACOSX_PACKAGE_LOCATION''' and '''TARGET PROPERTY MACOSX_BUNDLE_PLIST''' to put other files inside the bundle. Make sure to install your executables to the root install prefix (use the "DESTINATION ." argument to install()) so that they are visible to the user when they open the DMG. <br />
<br />
It seems to be impossible to put multiple executables inside a bundle using this generator; for that you should use the Bundle generator. However, you can include shared libraries by using '''fixup_bundle()''' from BundleUtilities.<br />
<br />
==PackageMaker (OSX only)==<br />
<br />
Mac OSX Package Maker packages. Requires Package Maker for creating the package.<br />
<br />
Some of the variables that you can use to customize the Package Maker generated package:<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_PREFLIGHT_SCRIPT || This script is launched just after the user clicked on the "Install" button. || - <br />
|-<br />
| CPACK_POSTFLIGHT_SCRIPT || This script is launched after the postinstall / postupgrade script or when the package has been || -<br />
|-<br />
| CPACK_POSTUPGRADE_SCRIPT || This script is launched after the files in the package have been installed. (Isn't an option for a postinstall script missing? According to Apple documentation, postinstall is executed the first time a package is installed and postupgrade all subsequent times) || -<br />
|-<br />
| CPACK_OSX_PACKAGE_VERSION || Set to the minimum OS X version you support. Choices are currently 10.3, 10.4 and 10.5 || 10.3, unless you specified features that require a higher OS X version (CPACK_DOWNLOAD_SITE, CPACK_COMPONENTS_ALL)<br />
|}<br />
<br />
This is a useful site that describes where the scripts get executed and what the arguments to the scripts are. See section "What about scripts?". http://s.sudre.free.fr/Stuff/PackageMaker_Howto.html . In summary the arguments correspond to $0 Script path, $1 Package path, $2 Target location, and $3 Target Volume.<br />
<br />
==OSXX11 (OSX only)==<br />
<br />
Mac OSX X11 Bundle. Requires hdiutil for creating the package.<br />
<br />
== Bundle (OSX only) ==<br />
<br />
=== Overview ===<br />
<br />
The Bundle generator (introduced in CMake 2.6) creates a compressed disk image containing an OSX bundle, whose contents are populated with CMake INSTALL() commands. This makes it possible to create bundles of arbitrary complexity while minimizing differences with installation on other platforms. For example, a bundle created with the bundle generator can contain multiple executable files, libraries generated by the build, third-party dependencies, etc.<br />
<br />
'''''Important Note:''''' Do '''not''' use the MACOSX_BUNDLE property on executables that will be packaged using the bundle-generator! Specifying MACOSX_BUNDLE creates a separate bundle for each individual executable at build-time; the structure of these bundles becomes redundant when the bundle generator consolidates multiple executables into a single bundle.<br />
<br />
=== Bundle Layout ===<br />
<br />
<pre><br />
${CPACK_BUNDLE_NAME}/<br />
Contents/<br />
Info.plist (copied from ${CPACK_BUNDLE_PLIST})<br />
MacOS/<br />
${CPACK_BUNDLE_NAME} (copied from ${CPACK_BUNDLE_STARTUP_COMMAND})<br />
Resources/<br />
(file contents defined by CMake INSTALL() commands)<br />
</pre><br />
<br />
* CPACK_BUNDLE_PLIST is the name of a file that becomes the Info.plist for the bundle. This could be a hard-coded file included with the program sources, a file generated with CONFIGURE_FILE, etc. Rationale: Info.plist can become arbitrarily complex, applications need to be able to specify its contents directly.<br />
<br />
* The bundle's Resources/ directory is populated with the files installed with CMake INSTALL() commands. Rationale: integrate well with CMake and other package generators (such as NSIS). Makes it easy to incorporate external dependencies (Qt, GTK) into the bundle.<br />
<br />
* CPACK_BUNDLE_STARTUP_COMMAND is the name of a file that will be executed when the user opens the bundle. It could be a binary or a script. This file should be present in the source or build tree after a build; CPackBundle will copy it into the correct place in the bundle. Rationale: for most non-trivial applications, simply running a binary is not enough. The following sample script demonstrates several common startup operations:<br />
** Starts X11 (required by GTK).<br />
** Updates DYLD_LIBRARY_PATH so that the application can locate libraries that are included in the bundle. This eliminates the need to run install_name_tool on libraries in the bundle, which is messy and error-prone. Useful for either Qt or GTK.<br />
** Updates PATH so the "main" application can easily run "child" binaries included in the bundle.<br />
** Sets-up some temporary files and environment variables required by (in this case) GTK.<br />
** Passes information to the application via the command line (in this case, paths to several application resources located in the bundle).<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# Author: Aaron Voisine <aaron@voisine.org><br />
# Inkscape Modifications: Michael Wybrow <mjwybrow@users.sourceforge.net><br />
# K-3D Modifications: Timothy M. Shead <tshead@k-3d.com><br />
<br />
K3D_BUNDLE="`echo "$0" | sed -e 's/\/Contents\/MacOS\/K-3D//'`"<br />
K3D_RESOURCES="$K3D_BUNDLE/Contents/Resources"<br />
K3D_TEMP="/tmp/k3d/$UID"<br />
K3D_ETC="$K3D_TEMP/etc"<br />
K3D_PANGO_RC_FILE="$K3D_ETC/pango/pangorc"<br />
<br />
echo "running $0"<br />
echo "K3D_BUNDLE: $K3D_BUNDLE"<br />
<br />
# Start X11 ...<br />
ps -wx -ocommand | grep -e '[X]11.app' > /dev/null<br />
if [ "$?" != "0" -a ! -f ~/.xinitrc ]; then<br />
echo "rm -f ~/.xinitrc" > ~/.xinitrc<br />
sed 's/xterm/# xterm/' /usr/X11R6/lib/X11/xinit/xinitrc >> ~/.xinitrc<br />
fi<br />
<br />
mkdir -p $K3D_TEMP<br />
cat << __END_OF_GETDISPLAY_SCRIPT__ > "$K3D_TEMP/getdisplay.sh"<br />
#!/bin/sh<br />
mkdir -p "$K3D_TEMP"<br />
<br />
if [ "\$DISPLAY"x == "x" ]; then<br />
echo :0 > "$K3D_TEMP/display"<br />
else<br />
echo \$DISPLAY > "$K3D_TEMP/display"<br />
fi<br />
__END_OF_GETDISPLAY_SCRIPT__<br />
chmod +x "$K3D_TEMP/getdisplay.sh"<br />
rm -f $K3D_TEMP/display<br />
open-x11 $K3D_TEMP/getdisplay.sh || \<br />
open -a XDarwin $K3D_TEMP/getdisplay.sh || \<br />
echo ":0" > $K3D_TEMP/display<br />
<br />
while [ "$?" == "0" -a ! -f $K3D_TEMP/display ];<br />
do<br />
#echo "Waiting for display $K3D_TEMP/display"<br />
sleep 1;<br />
done<br />
export "DISPLAY=`cat $K3D_TEMP/display`"<br />
<br />
ps -wx -ocommand | grep -e '[X]11' > /dev/null || exit 11<br />
<br />
# Setup temporary runtime files<br />
rm -rf "$K3D_TEMP"<br />
<br />
# Because the bundle could be located anywhere at runtime, we have to<br />
# create temporary copies of the Pango configuration files that<br />
# reflect our current location<br />
mkdir -p "$K3D_ETC/pango"<br />
sed -e 's|/opt/local/etc|'"$K3D_ETC|g" "$K3D_RESOURCES/etc/pango/pangorc" > "$K3D_ETC/pango/pangorc"<br />
sed -e 's|/opt/local|\"'"$K3D_RESOURCES|g" -e "s/\.so/.so\"/g" "$K3D_RESOURCES/etc/pango/pango.modules" > "$K3D_ETC/pango/pango.modules"<br />
cp -f "$K3D_RESOURCES/etc/pango/pangox.aliases" "$K3D_ETC/pango/pangox.aliases"<br />
<br />
export "DYLD_LIBRARY_PATH=$K3D_RESOURCES/lib"<br />
export "FONTCONFIG_PATH=$K3D_RESOURCES/etc/fonts"<br />
export "PANGO_RC_FILE=$K3D_PANGO_RC_FILE"<br />
export "PATH=$K3D_RESOURCES/bin:$PATH"<br />
<br />
#export<br />
exec "$K3D_RESOURCES/bin/k3d" "--log-level=debug" "--plugins=$K3D_RESOURCES/lib/k3d/plugins" "--share=$K3D_RESOURCES/share/k3d" "--ui=$K3D_RESOURCES/lib/k3d/uiplugins/k3d-ngui.module"<br />
</pre><br />
<br />
* The bundle is then stored in a compressed disk image. Rationale: de-facto standard mechanism for distributing bundles.<br />
<br />
=== Required CMake Variables ===<br />
<br />
The prototype bundle generator uses the following variables:<br />
<br />
* CPACK_PACKAGE_FILE_NAME - provides the name of the final compressed disk image (the name of the file that is distributed).<br />
* CPACK_PACKAGE_ICON - provides the icon for the mounted disk image (appears after the user mounts the disk image).<br />
* CPACK_BUNDLE_NAME - provides the bundle name (displayed in the finder underneath the bundle icon).<br />
* CPACK_BUNDLE_ICON - provides the bundle icon (displayed in the /Applications folder, on the dock, etc).<br />
* CPACK_BUNDLE_PLIST - path to a file that will become the bundle plist.<br />
* CPACK_BUNDLE_STARTUP_COMMAND - path to a file that will be executed when the user opens the bundle. Could be a shell-script or a binary.<br />
<br />
=== Known Issues ===<br />
<br />
* [http://public.kitware.com/Bug/view.php?id=7523 0007523: CPack OSX bundle generator can fail when assigning a custom volume icon.]<br />
<br />
=== TODO ===<br />
<br />
* Detect attempts to use the bundle generator with MACOSX_BUNDLE.<br />
* Generate a default Info.plist file if CPACK_BUNDLE_PLIST is not defined.<br />
* Support fixing-up binaries with install_name_tool, eliminating the need to run a script that sets DYLD_LIBRARY_PATH.<br />
* Add arbitrary files (such as background images, READMEs, etc) to the disk image - this use-case is distinct from adding files to the bundle with INSTALL().<br />
* Provide an option or alternative to CPACK_BUNDLE_STARTUP_COMMAND that simply executes one of the files installed in the bundle. Presumably, this should be a symlink to a binary or script.<br />
<br />
==CygwinBinary (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin package. Requires bzip2 for creating the package.<br />
<br />
==CygwinSource (Cygwin only)==<br />
<br />
Tar Bzip2 compressed Cygwin source package. Requires bzip2 for creating the package.<br />
<br />
==DEB (UNIX only)==<br />
<br />
Debian packages (2.0 version only, see the debian-binary file). In CMake cvs since July 2007, will be in 2.6.0. With CPack 2.4.x you can use the approach described in [[CMakeUserUseDebian]] (Requires only ar for creating the package). Warning: due to an incompatibility between GNU-ar and BSD-ar this is not a long-term recommended solution.<br />
Instead you should switch to the solution implemented in 2.6.x where a BSD-ar implementation was integrated in CPack.<br />
<br />
Reference: [libapt-inst] Should support both BSD and SysV ar formats<br />
* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161593 <br />
<br />
Note:<br />
Only binary package are supported. source package do not really make sense since build process is cmake driven.<br />
<br />
Here are the variables needed for a binary package:<br />
<br />
=== control file (aka DEBIAN/control) for binary package ===<br />
<br />
Specific variables are needed to generate the control file for debian package. This file is created automatically using the following variables, some of which are mandatory and some are optional. <br />
See also: [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-binarycontrolfiles]<br />
<br />
'''package name'''<br />
<br />
* debian policy enforce lower case for package name<br />
* Package: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_NAME is not set CPACK_PACKAGE_NAME (lower case will be used)<br />
<br />
'''version'''<br />
<br />
* Version: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_VERSION is not set CPACK_PACKAGE_VERSION<br />
<br />
'''arch'''<br />
<br />
* Architecture: (mandatory)<br />
* if not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE will be set to i386<br />
Notes:<br />
* should be set via: dpkg --print-architecture<br />
* There is no such thing as i686 architecture on debian, you should use i386 instead<br />
<br />
'''depends'''<br />
<br />
* Depends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_DEPENDS<br />
* eg.:<br />
<pre><br />
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12)")<br />
</pre><br />
Notes:<br />
* have a look at GET_PROPERTY(result GLOBAL ENABLED_FEATURES), this returns the successful FIND_PACKAGE() calls, maybe this can help<br />
* TODO: automate 'objdump -p | grep NEEDED'<br />
<br />
'''maintaner'''<br />
<br />
* Maintainer: (mandatory)<br />
** valid email is required<br />
* if CPACK_DEBIAN_PACKAGE_MAINTAINER is not set, CPACK_PACKAGE_CONTACT will be used instead<br />
<br />
'''description'''<br />
<br />
* Description: (mandatory)<br />
* if CPACK_DEBIAN_PACKAGE_DESCRIPTION is not set CPACK_PACKAGE_DESCRIPTION_SUMMARY will be used instead.<br />
<br />
'''section'''<br />
<br />
* Section: (recommended)<br />
* if not set CPACK_DEBIAN_PACKAGE_SECTION will default to 'devel'<br />
<br />
'''priority'''<br />
<br />
* Priority: (recommended)<br />
* if not set CPACK_DEBIAN_PACKAGE_PRIORITY will be set to "optional"<br />
<br />
'''recommends'''<br />
<br />
* Recommends:<br />
* You should set: CPACK_DEBIAN_PACKAGE_RECOMMENDS<br />
<br />
'''Suggests'''<br />
<br />
* Suggests:<br />
* You should set: CPACK_DEBIAN_PACKAGE_SUGGESTS<br />
<br />
'''Control Extra'''<br />
* Additional control files (optional)<br />
* In order to perform pre-, or post-install configuration, certain files can be provided in the DEBIAN/ folder in the debian package (postinst, preinst, postrm, prerm)<br />
* You should set: CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA <br />
* E.g.<br />
<pre><br />
set( CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA "${CMAKE_CURRENT_SOURCE_DIR}/CMake/debian/postinst;${CMAKE_CURRENT_SOURCE_DIR}/CMake/debian/prerm;" )<br />
</pre><br />
<br />
=== Source (for reference only) ===<br />
<br />
Here are the variables needed for a source package (not implemented):<br />
<br />
* For debian source packages:<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles debian/control]<br />
<br />
* .dsc<br />
* see also [http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles]<br />
<br />
Most of them are identical with the binary package, with exception:<br />
<br />
'''builds-depends'''<br />
<br />
* DEBIAN_PACKAGE_BUILDS_DEPENDS<br />
* eg.: <br />
<pre><br />
"debhelper (>> 5.0.0), libncurses5-dev, tcl8.4"<br />
</pre><br />
<br />
===Debian Generator specific settings===<br />
{|<br />
|- bgcolor="#abcdef"<br />
! Variable Name || Description || Example<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_MAINTAINER || The maintenainer informations || Firstname Lastname <email@example.com><br />
|-<br />
| CPACK_PACKAGE_DESCRIPTION_SUMMARY || Package short description || Here is my short description<br />
|-<br />
| CPACK_PACKAGE_DESCRIPTION || Package description || Here is my long description<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_DEPENDS || Package dependencies (use dpkg -s <packagename> to retrieve version) || libc6 (>= 2.7-18)<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA || This variable allow advanced user to add custom script to the control.tar.gz (inside the .deb archive) || ${CMAKE_CURRENT_SOURCE_DIR}/postinst<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_SECTION || Package section (see http://packages.debian.org/stable/) || Network<br />
|-<br />
| CPACK_DEBIAN_PACKAGE_VERSION || Package version || ${CPACK_PACKAGE_VERSION}+lenny1<br />
|-<br />
|}<br />
<br />
=== External references ===<br />
<br />
* http://wiki.debian.org/HowToPackageForDebian<br />
<br />
==RPM (Unix Only)==<br />
<br />
Binary RPM packages are supported by CMake (more precisely by CPack) since CMake 2.6.0.<br />
If you use CMake 2.4.x (or you want to build source RPM)<br />
you may use the [[CMakeUserUseRPMTools]] module.<br />
<br />
The CPack RPM generator supports [[CMake:Component_Install_With_CPack|CPack Component installation]]. You can find details about the implementation [[http://public.kitware.com/Bug/view.php?id=7645 here]].<br />
<br />
=== CPack RPM usage ===<br />
The CPack RPM generator is similar to other CPack generators. Its execution is controlled using:<br />
* generic CPACK_xxxx variables see [[CMake:CPackConfiguration|CPack variables]]<br />
* specific CPACK_RPM_xxxx variables see generator specific wiki pages<br />
<br />
Since CMake/CPack 2.8.0, a detailed description of how to use the CPACK_RPM_xxxx is available in this article or from the CMake command line:<br />
<br />
<pre><br />
cmake --help-module CPackRPM<br />
</pre><br />
<br />
If you use [[CMake:Packaging_With_CPack#Using_CPack_with_CMake|CPack with CMake]] with the Makefile<br />
generator you usually launch:<br />
<pre><br />
cd build_dir<br />
make package<br />
</pre><br />
<br />
However if you want more command line control over the CPack run you may launch:<br />
<br />
<pre><br />
cd build_dir<br />
cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -D CPACK_RPM_SPEC_INSTALL_POST="/bin/true" -G RPM<br />
</pre><br />
<br />
this will launch CPack with additionnal CPACK_RPM_xxxx variables definitions which <br />
may be used by CPack RPM generator.<br />
<br />
<br />
=== CPack RPM generators specific settings ===<br />
CPack RPM specific variables are used to generate an RPM spec file<br />
which will be processed by the ''rpmbuild'' tool.<br />
A specific variable may be<br />
* ''optional'', the variable may or may not be set and its value is not needed for building a valid spec file.<br />
* '''mandatory''', the variable must be set because we need a value for building a valid spec file.<br />
** '''mandatory with default value''', the variable must be set but a default value is provided.<br />
** '''mandatory''', the variable must be set and no default value is provided.<br />
<br />
Here is the list of CPack RPM specific variables (''some variable are not yet supported because there are some patches pending''):<br />
<br />
{| border="1" cellpadding="2"<br />
|-bgcolor="#abcdef"<br />
||Variable Name <br />
||Description <br />
||Default value <br />
|-<br />
| '''CPACK_RPM_PACKAGE_SUMMARY''' || The RPM package summary || CPACK_PACKAGE_DESCRIPTION_SUMMARY <br />
|-<br />
| '''CPACK_RPM_PACKAGE_NAME''' || The RPM package name || CPACK_PACKAGE_NAME<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VERSION''' || The RPM package version || CPACK_PACKAGE_VERSION<br />
|-<br />
| ''CPACK_RPM_PACKAGE_ARCHITECTURE'' || The RPM package architecture. This may be set to "noarch" if you know you are building a noarch package. || -<br />
|-<br />
| '''CPACK_RPM_PACKAGE_RELEASE''' || The RPM package release. This is the numbering of the RPM package itself, i.e. the version of the packaging and not the version of the content (see CPACK_RPM_PACKAGE_VERSION). One may change the default value if the previous packaging was buggy and/or you want to put here a fancy Linux distro specific numbering.|| 1<br />
|-<br />
| '''CPACK_RPM_PACKAGE_LICENSE''' || The RPM package license policy. || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_GROUP''' || The RPM package group (see /usr/share/doc/rpm-*/GROUPS ) || "unknown"<br />
|-<br />
| '''CPACK_RPM_PACKAGE_VENDOR''' || The RPM package vendor || CPACK_PACKAGE_VENDOR if set or "unknown" if not set<br />
|-<br />
| '''CPACK_RPM_PACKAGE_DESCRIPTION''' || The RPM package description || The content of CPACK_PACKAGE_DESCRIPTION_FILE if set or "no package description available" if not set<br />
|-<br />
| ''CPACK_RPM_PACKAGE_REQUIRES'' || May be used to set RPM dependencies. see [[http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html RPM dependencies specification]]) for precise syntax. Note that you must enclose the complete requires string between quotes, for example:<br /> set(CPACK_RPM_PACKAGE_REQUIRES "python >= 2.5.0, cmake >= 2.8")|| - <br />
|-<br />
| ''CPACK_RPM_PACKAGE_PROVIDES'' || May be used to set the virtual packages provided by the RPM. It is somewhat complimentary to CPACK_RPM_PACKAGE_REQUIRES, but note that you do not need to list things like libraries, etc. here, since rpmbuild will figure that out by itself when generating the RPM. Most packages leave this blank. NOTE: This variable was added in cmake 2.8.1 (see [[http://public.kitware.com/Bug/view.php?id=9584 Bug9584]]).|| - <br />
|-<br />
| ''CPACK_RPM_SPEC_INSTALL_POST'' || May be used to set an RPM post-install command inside the spec file. For example setting it to "/bin/true" may be used to prevent rpmbuild to strip binaries (see [[http://public.kitware.com/Bug/view.php?id=7435 Bug7435]]). This is '''not to be confused''' with .spec %post section (the action specified here is being invoked at ''rpmbuild'' time, not ''post-install-package'' time at user side) || -<br />
|-<br />
| ''CPACK_RPM_SPEC_MORE_DEFINE'' || May be used to add any %define lines to the generated spec file.|| -<br />
|-<br />
| ''CPACK_RPM_USER_BINARY_SPECFILE'' || May be used to specify a user provided spec file instead of generating one. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679]]|| -<br />
|-<br />
| ''CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE'' || May be used to generate a '''template''' for a user provided spec file. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679]]|| -<br />
|-<br />
| ''CPACK_RPM_<POST/PRE>_<UN>INSTALL_SCRIPT_FILE'' || The content of the specified files will be embedded in the RPM spec file in the appropriate sections. This is an feature which currently needs a patch see [[http://public.kitware.com/Bug/view.php?id=8988 Bug8988]] || -<br />
|-<br />
| ''CPACK_RPM_PACKAGE_DEBUG'' || May be set when invoking cpack in order to trace debug informations during CPack RPM run. For example you may launch CPack like this ''cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM'' || -<br />
|}<br />
<br />
=== CPack RPM currently pending bugs/features ===<br />
Here the may-be-incomplete lists of pendings bugs/features request<br />
linked to CPackRPM:<br />
<br />
* Support for COMPONENT [[http://public.kitware.com/Bug/view.php?id=7645 Bug7645-PreliminaryPatchUnderway]] this one will need more work since it depends on [[http://public.kitware.com/Bug/view.php?id=9900 Bug9900]]<br />
* RPM Post/Pre (un)install script support [[http://public.kitware.com/Bug/view.php?id=8988 Bug8988-Fixed since 2.8.1]]<br />
* Builtin documentation with ''cmake --help-module CPackRPM'' [[http://public.kitware.com/Bug/view.php?id=9029 Bug9029-Fixed since 2.8.0]]<br />
* RPM 4.6.x support <br />
** Fedora Core 10 fix, [[http://public.kitware.com/Bug/view.php?id=8967 Bug8967-Fixed since 2.8.1]]<br />
** Mandriva 2009.1 fix, [[http://public.kitware.com/Bug/view.php?id=9031 Bug9031-Fixed since 2.8.1]]<br />
* Support USER supplied "Provides" [[http://public.kitware.com/Bug/view.php?id=9584 Bug9584-Fixed since 2.8.1]]<br />
* Related bugs<br />
** Do not include include directories in %file section [[http://public.kitware.com/Bug/view.php?id=9654 Bug9654-Fixed since 2.8.1]]<br />
** Symlink not packaged [[http://public.kitware.com/Bug/view.php?id=9927 Bug9927-Fixed since 2.8.1]]<br />
* Support of USER specified spec file [[http://public.kitware.com/Bug/view.php?id=9679 Bug9679-Fixed since 2.8.1]]<br />
* RPM 4.7.1 / Fedora 11 Issue, [[http://public.kitware.com/Bug/view.php?id=9872 Bug9872-Fixed since 2.8.1]]<br />
* RPM Generator, spaces in CPACK_PACKAGE_NAME cause error [[http://public.kitware.com/Bug/view.php?id=9932 Bug9932-Unfixable]]<br />
<br />
=== CPack RPM Historical Notes ===<br />
<br />
CPackRPM included along with CMake 2.8.1 is provided many new features and bug fixes<br />
--[[User:Erk|Erk]] 14:33, 20 February 2010 (UTC)<br />
<br />
The binary CPackRPM generator should now work for many RPM based distribution and rpmbuild version.<br />
[[User:Erk|Erk]] was granted CVS commit right for CPackRPM and he's maintaining and improving it as long<br />
as spare time is available --[[User:Erk|Erk]] 14:30, 20 February 2010 (UTC)<br />
<br />
The built-in CPack support for RPM is based on the work done in the [[CMakeUserUseRPMTools|RPM]] module.<br />
The built-in CPack 2.6.x support for RPM is for '''binary package only''' but <br />
the binary RPM package built faster using CPack than [[CMakeUserUseRPMTools]] module.<br />
This restriction is due to both a lack of time of the implementor (--[[User:Erk|Erk]] 05:01, 7 September 2007 (EDT))<br />
and some [[CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues|design issues]] in current CPack .<br />
<br />
<br />
The [[CMakeUserUseRPMTools]] module should be usable both with CMake 2.4.x and forthcoming CMake 2.6.x.<br />
<br />
For an enhanced version of these modules, take a look at this discussion http://www.cmake.org/pipermail/cmake/2007-July/014945.html.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake/MatlabMex&diff=62624CMake/MatlabMex2018-04-24T18:46:49Z<p>Brad.king: /* Cygwin */</p>
<hr />
<div>=What are MATLAB MEX files?=<br />
<br />
MEX files are functions written in C or C++ that are callable in the MATLAB scripting language in a MATLAB interpretor. [http://www.mathworks.com/matlab MATLAB] is a 'Matrix Laboratory', a general purpose scientific scripting language owned by [http://www.mathworks.com The MathWorks] company.<br />
<br />
Details of writing MEX files can be found in the [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_external/bp_kqh7.html MATLAB documentation].<br />
<br />
==Before you begin==<br />
<br />
MATLAB is a language with good syntax for working with matrices, a variety of functions, excellent documentation, and it is ubiquitous throughout the academic, scientific community. On the other hand, it is extremely slow, has poor memory utilization, is prohibitively expensive, sees little use outside academia, has a language syntax that is only good for simple procedural scripting, is closed source, and has numerous bugs. Writing MEX files is often an attempt to address some of these limitations -- speed and memory usage. However, it is a difficult and not very elegant solution. Instead, researchers should consider using superior products, such as [http://scipy.org SciPy], [http://www.scilab.org SciLab], [http://www.sagemath.org/ Sage], or [http://www.gnu.org/software/octave/index.html Octave].<br />
<br />
=Why would you want to use CMake for creating MEX files?=<br />
<br />
If you have a very small project that consists of only a single source code file that does not link to other libraries, then simply using the MEX compiler at the command line is all that you need. However, if your project is non-trivial, there are many advantages to using CMake. A make system allows you to recompile and link ''only'' the files that change during development and to perform parallel builds. CMake provides a configuration system for finding libraries on systems. The are many advantages to organizing and controlling the build system in a simple and powerful way, which CMake can do, [[Really_Cool_CMake_Features | among other things]].<br />
<br />
=How do you use CMake with MATLAB?=<br />
<br />
== Background on the MATLAB MEX "compiler" ==<br />
<br />
MATLAB comes with a MEX "compiler". It is not a true compiler, but a [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_external/f24338.html frontend build script] to the compiler of your choice. On MS Windows it is a perl script, and on Unix-like systems it is a shell script, although they have the same user interface. Issuing <br />
<pre><br />
mex -setup<br />
</pre><br />
allows you to setup the configuration file the mex script uses to determine which compiler it will use, the flags it will pass, etc. <br />
<pre><br />
mex -v <br />
</pre><br />
shows the compiler and settings the build script is using.<br />
<br />
The MEX compiler can process C, C++, or Fortran code. The code must contain a gateway function with specific syntax that MATLAB hooks into. Primary MATLAB itself is written is C, and a variety of functions are available in the ''mex.h'' header for interrogating MATLAB data structures, allocating memory in a way that it is controlled by MATLAB, etc. The result of this process is a shared library (dll) ''mexfile'' that is loaded by by the MATLAB interpretor when the basename is found in MATLAB's path.<br />
<br />
== How can CMake fit into this process? ==<br />
<br />
There are three basic approaches to utilize CMake for the process of generating mexfiles.<br />
<br />
=== Try to emulate the logic built into the mex build script in CMakeLists.txt ===<br />
<br />
Since mexfiles are simply native shared libraries with some special functions, etc., it is possible to bypass the mex build script completely. The logic built into the mex built script can be replaced by appropriate scripting of the ''CMakeLists.txt''. <br />
<br />
Unfortunately, this approach requires significant effort, and it is difficult to maintain. In addition to the mex gateway function, a MEX file requires specific preprocessor definitions, compiler flags, link scripts, linked libraries, etc. These must be reproduced in the CMakeLists.txt. The options vary across compilers and across platforms. Furthermore, MathWorks produces new MATLAB versions twice a year, and these options change across versions. Configuration must be maintained for every MATLAB version that is desired, and new releases of MATLAB likely break the build process.<br />
<br />
=== Tell CMake to treat the mex build script as the project's compiler ===<br />
<br />
The other option is to tell CMake to treat the mex build script as the project's compiler. This approach dulls the power of CMake in some cases due to the limited capabilities of the mex script, but it makes project much more maintainable. This article describes this approach.<br />
<br />
If the ''mex'' script is in the system's ''PATH'' environment variable, setting the ''CC'' or ''CXX'' environmental variable is all that is required:<br />
<pre><br />
CC=mex CXX=mex cmake /path/to/project/source<br />
</pre><br />
<br />
This method requires a patched version of CMake. The patch can be obtained [http://public.kitware.com/Bug/view.php?id=9240 here].<br />
<br />
There are some differences from normal CMake usage when using the mex build script as the system compiler. Instead of configuring additional compiler flags from within CMake, compiler flags for the underlying compiler must be set in the mexopts configuration file. Compiler flags configured in CMake should be [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_external/f24338.html options sent to the mex compiler].<br />
<br />
It is still possible to use the <br />
<pre><br />
include_directories()<br />
link_directories()<br />
target_link_libraries()<br />
</pre><br />
scripting directives in the project's CMakeLists.txt.<br />
<br />
Since all mexfiles are shared libraries, <br />
<pre><br />
add_executable()<br />
add_library(library_name STATIC sources.cpp)<br />
</pre><br />
are not valid ways for generating targets. CMake targets should be made with <br />
<pre><br />
add_library(library_name SHARED sources.cpp)<br />
</pre><br />
or<br />
<pre><br />
add_library(library_name MODULE sources.cpp)<br />
</pre><br />
<br />
===Build your own static library using CMake, and then linking at the final stage===<br />
This is a fairly neat workaround for the poorness of MEX. In principle, it allows the user to build an abitrary static library using the usual build toolchain, and then only invoke the mex compiler at the final stage, linking everything together into a MEX file. It sidesteps the logical checks that MEX thinks it needs to carry out.<br />
<br />
The method goes something like this:<br />
Replace your mexFunction() and mexAtExit() and other routines that MATLAB would expect to find with some placeholder. e.g. __mexFunction__() and __at_exit__().<br />
<br />
Compile a static library using a suitably defined CMakeLists.txt that uses the usual build tools, e.g. gcc.<br />
<br />
Create a stub function that wraps your __mexFunction__() etc with the MATLAB defined functions mexFunction() etc. I.e. it simply enters the function and calls the alternative version. An example is [[File:mex_stub.cpp]].<br />
<br />
Add the following to your CMakeLists.txt file:<br />
<pre><br />
ADD_CUSTOM_COMMAND(TARGET ${PROJECT_NAME}<br />
POST_BUILD<br />
COMMAND ./mex_link.sh ${PROJECT_NAME} ${MEX_SAVE_PATH}<br />
)<br />
</pre><br />
<br />
This instructs CMake to call ./mex_link.sh when the static library has been built.<br />
<br />
mex_link.sh is a short script that compiles mex_stub.c (or cpp) and then calls mex to link everything together. A suitable bash script would be:<br />
<pre><br />
#!/bin/sh<br />
<br />
OUTPUT=$1<br />
STATIC_LIB_NAME=$OUTPUT<br />
MOVE_LOCATION=$2<br />
LINKER_FLAGS=''<br />
<br />
echo 'Running godawful mex linking hack...'<br />
# mex_stub.o compiled with:<br />
gcc-4.1 -g -Wall -fPIC -std=c99 -pthread -DMX_COMPAT_32 -DMATLAB_MEX_FILE \ <br />
-I/opt/matlab/latest/extern/include -c mex_stub.c -o mex_stub.o<br />
mex -g -cxx CC='gcc-4.1' CXX='gcc-4.1' LD='gcc-4.1' -L./ -lpthread -lgthread-2.0 \ <br />
-lrt -lglib-2.0 -l$STATIC_LIB_NAME $LINKER_FLAGS -output $OUTPUT mex_stub.o<br />
mv $OUTPUT.mexa64 $MOVE_LOCATION<br />
</pre><br />
<br />
The onus is on the user to get all the linker flags correct. Certainly, "-lpthread -lgthread-2.0 -lrt -lglib-2.0" are all project dependent flags included as an example.<br />
<br />
MEX_SAVE_PATH will also need to be defined, often simply as:<br />
<pre><br />
SET(MEX_SAVE_PATH "${CMAKE_SOURCE_DIR}")<br />
</pre><br />
<br />
The result of the make should be a built MEX file that works fine with MATLAB.<br />
<br />
Notes:<br />
The following flags should be added as compile flags -fPIC -DMX_COMPAT_32 -DMATLAB_MEX_FILE (the last 2 just being defines) using (I can't remember if the -std=c99 is optional or not):<br />
<pre><br />
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC -std=c99 -DMX_COMPAT_32 -DMATLAB_MEX_FILE")<br />
</pre><br />
<br />
Adding something like the following to your CMakeLists.txt file will cause make clean to work properly:<br />
<pre><br />
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${MEX_SAVE_PATH}/${PROJECT_NAME}.mexa64;mex_stub.o")<br />
</pre><br />
<br />
This technique has only been tested with GCC under linux. Not sure if it will work anywhere else.<br />
<br />
=Hello World Example=<br />
<br />
The source code for a "hello world" project can be [http://github.com/thewtex/matlab-cmake-hello-world/downloads downloaded] or [http://github.com/thewtex/matlab-cmake-hello-world/tree/master examined].<br />
<br />
To compile this example, unpack the source, then<br />
<pre><br />
mkdir hello_b<br />
cd hello_b<br />
CC=/path/to/mex CXX=/path/to/mex /path/to/cmake /path/to/source<br />
make<br />
</pre><br />
<br />
Next, at a MATLAB prompt,<br />
<pre><br />
cd /path/to/hello_b/tests/<br />
hello<br />
</pre><br />
<br />
This project has successfully been tested on the following setups:<br />
* 32-bit Linux/MATLAB R2007a/gcc-4.1.1<br />
* 64-bit Linux/MATLAB R2007a/gcc-4.1.1<br />
* 64-bit Linux/MATLAB R2009a/gcc-4.1.2<br />
* 32-bit WindowsXP/MATLAB R2008a/[http://gnumex.sourceforge.net/ gnumex]-MSYS-MinGW<br />
* 32-bit WindowsXP/MATLAB R2008a/[http://gnumex.sourceforge.net/ gnumex]-Cygwin-MinGW<br />
<br />
=More complex example: ITK based image reader=<br />
<br />
[http://github.com/thewtex/matlab-itk-import/tree/master Here] is a more complex project that demonstrates finding external projects, adding additional include directories, and linking to libraries. <br />
<br />
This project creates an [http://www.itk.org ITK] based image reader that supports [[ITK_File_Formats | all the image formats accessible to ITK ]].<br />
<br />
=Platform specific issues=<br />
<br />
== Windows == <br />
<br />
The mex build script in Windows is set up to only look for static libraries when linking, not dll's.<br />
<br />
=== Gnumex ===<br />
<br />
[http://gnumex.sourceforge.net Gnumex] is a utility designed to help setup the mexopts.bat mex configuration file to use GNU tools on Windows. Unfortunately, the mex build script does not look for static libraries made with the GNU toolchains correctly. Apply the following patch to ${MATLAB_ROOT}/bin/mex.pl so that the script can see those libraries.<br />
<br />
<pre><br />
--- mex.pl.backup 2009-07-03 10:46:30.095025600 -0500<br />
+++ mex.pl 2009-07-04 19:55:04.241083200 -0500<br />
@@ -1103,6 +1103,7 @@<br />
my $lib_found = 0;<br />
foreach my $lib_dir (@IMPLICIT_LIB_DIRS) {<br />
my $win_name = mexCatfile($lib_dir, $1 . ".lib");<br />
+ my $mingwwin_name = mexCatfile($lib_dir, "lib" . $1 . ".a");<br />
my $unx_name = mexCatfile($lib_dir, "lib" . $1 . ".lib");<br />
if (-e $win_name) {<br />
$IMPLICIT_LIBS .= " " . smart_quote($win_name);<br />
@@ -1112,6 +1113,10 @@<br />
$IMPLICIT_LIBS .= " " . smart_quote($unx_name);<br />
$lib_found = 1;<br />
last;<br />
+ } elsif (-e $mingwwin_name) {<br />
+ $IMPLICIT_LIBS .= " " . smart_quote($mingwwin_name);<br />
+ $lib_found = 1;<br />
+ last;<br />
}<br />
}<br />
<br />
</pre><br />
<br />
=== MSYS ===<br />
<br />
In order to run the mex build script in [http://www.mingw.org/wiki/MSYS MSYS], a script such as the following is required:<br />
<pre><br />
#!/bin/sh<br />
MATLAB_DIR='/c/Program Files/MATLAB/R2008a'<br />
"${MATLAB_DIR}/sys/perl/win32/bin/perl.exe" "${MATLAB_DIR}/bin/mex.pl" "$@"<br />
</pre><br />
Place it in a location such as ''/usr/local/bin/mex''.<br />
<br />
Use the CMake Generator (-G switch to cmake.exe) ''MSYS Makefiles''.<br />
<br />
=== Cygwin ===<br />
<br />
In order to run the mex build script in [http://www.cygwin.com/ Cygwin], a script such as the following is required:<br />
<pre><br />
#!/bin/sh<br />
MATLAB_DIR='C:\Program Files/MATLAB/R2008a'<br />
"${MATLAB_DIR}/sys/perl/win32/bin/perl.exe" "${MATLAB_DIR}/bin/mex.pl" "$@"<br />
</pre><br />
Place it in a location such as ''/usr/local/bin/mex''<br />
<br />
Use the make.exe found [http://www.cmake.org/files/cygwin/ here].<br />
<br />
Use the CMake Generator (-G switch to cmake.exe) ''Unix Makefiles''.<br />
<br />
[[Image:Example.jpg]]<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=BundleUtilitiesExample&diff=62623BundleUtilitiesExample2018-04-24T18:43:52Z<p>Brad.king: /* Overview */</p>
<hr />
<div>== Overview ==<br />
CMake 2.6.2 includes a new module called 'BundleUtilities'. This module is intended to make the task of creating a fully standalone OS X application bundle much easier than before. It still requires some setup on your part though. In CMake 2.8, the module was ported to Linux and Windows. In this example we will walk through the necessary files and CMake code that are needed to use the 'BundleUtilities.cmake' effectively. Get the project [[Media:QtTest-Package-Example.zip]].<br />
<br />
== Basic Flow ==<br />
The CMake code in the example does a few things.<br />
* It has install commands for targets built by the CMake code.<br />
* It has an install command for Qt plugins<br />
* It has an install command for creating a qt.conf file<br />
* It has an install command for executing CMake code at install time. This code uses BundleUtilities which gathers and includes prerequisites into the application bundle. On Mac OS X, BundleUtilities also modifies the install names.<br />
<br />
== Additions to your CMakeLists.txt File ==<br />
A simpler version of this example would have something like:<br />
<pre><br />
set(APPS ...) # paths to executables<br />
set(DIRS ...) # directories to search for prerequisites<br />
INSTALL(CODE "<br />
include(BundleUtilities)<br />
fixup_bundle(\"${APPS}\" \"\" \"${DIRS}\")<br />
" COMPONENT Runtime)<br />
</pre><br />
<br />
But since we include Qt plugins, we use the second argument to fixup_bundle().<br />
<br />
After all this is added to your project, rerun cmake on your project, build your project and finally try 'make install' or run the 'Installation' target from Xcode. You will see lots of text output during the installation phase indicating what is currently being performed. After all the libraries are copied to the install tree, a verification phase will be performed to make sure the application bundle is properly created. <br />
Assuming the verification has passed you should now have a QtTest.app that you can place on another computer and successfully run.<br />
<br />
To create a package, one can execute cpack -G <generator name> on the CMake generated CPackConfig.cmake file.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CMake:Experiments_With_Lua&diff=62622CMake:Experiments With Lua2018-04-24T18:36:12Z<p>Brad.king: </p>
<hr />
<div>Here [[File:CMakeLua.zip]] is a source tree for a CMake that also accepts Lua as input. All cmake commands are wrapped and one (get_property) has also been converted to be a function as a test case. This is just an experiment. There is a LuaTest test case (found under CMake/Tests) that works and is shown below. All cmake commands are lower case and are prepended with cm_. I'm not well versed on Lua and this is not a complete conversion. If a listfile ends in .lua then it will be parsed as lua code, otherwise it will be parsed using the usual CMake language.<br />
<br />
<pre><br />
-- a simple test case<br />
cm_project ("LuaTest");<br />
<br />
cm_add_executable ("LuaTest", "simple.cxx");<br />
<br />
sources = {<br />
"simpleLib.cxx",<br />
"simpleCLib.c", <br />
"simpleWe.cpp"<br />
}<br />
<br />
cm_add_library ("simpleLib", "STATIC", unpack(sources));<br />
<br />
cm_target_link_libraries ("LuaTest", "simpleLib");<br />
<br />
print("The location of simpleLib is: " .. <br />
cm_get_property("TARGET", "simpleLib", "LOCATION"));<br />
</pre><br />
<br />
----<br />
<br />
== Notes ==<br />
* The original attached file only seems to support the Makefile generator.<br />
* Bootstrap doesn't work. Use an existing version of CMake to build instead of bootstrap.<br />
<br />
== Comment ==<br />
<br />
The 'unpack(sources)' call feels pretty unnatural. This is easily avoided by using a table (array of strings) instead of a variable argument. But this brings up a bigger issue. Different users may package their data in different ways. We should probably try to support these different ways (within reason). This attached program demonstrates how to use an intermediate function to handle arguments passed in as varargs, or as a table, or as nested tables, or even as interspersed tables and strings.<br />
A simple example is attached here: [[File:FlexibleArgumentHelper.zip]]<br />
<br />
Since the current Lua binding seems to be fairly clever and compact by centralizing the interface into a single function, rather than changing this and implementing a lot more C code, we can instead create an intermediate helper function that is implemented completely in Lua. This helper function then actually becomes the public API and the the direct C/Lua binding can be thought of as a private API function. This Lua function then handles all the argument variations and sanitizes the input into what the C/Lua interface expects.<br />
<br />
Similarly, this approach can be used to return values in ways that may seem more natural to a scripter. For example, for functions that return values through one of the parameters, the Lua function could re-arrange it so that these values are returned through the normal return value mechanism.<br />
<br />
This example uses a simple recursive function to parse the table. This allows for some interesting combinations:<br />
We could pass like before:<br />
<br />
<pre><br />
cm.add_library ("simpleLib", cm.STATIC, unpack(sources));<br />
</pre><br />
<br />
We could pass as a table instead:<br />
<pre><br />
cm.add_library ("simpleLib", cm.STATIC, sources);<br />
</pre><br />
<br />
<br />
We can have nested tables:<br />
<pre><br />
another_table = { "file1.c", {"file2.c", "file3.c"}, {{"file4.c"}} }<br />
cm.add_library ("simpleLib", cm.STATIC, another_table);<br />
</pre><br />
<br />
We can also combine, and intersperse them:<br />
<pre><br />
cm.add_library ("simpleLib", cm.STATIC, sources, "another_file.c", another_table);<br />
</pre><br />
<br />
<br />
== External Links ==<br />
To make experimentation a little easier, we have set up a Mercurial repository at:<br />
http://www.assembla.com/spaces/CMakeLua<br />
<br />
We are using Tailor and Mercurial to try to keep these experimental changes in sync with CVS head which gives us more time to play with the code (to avoid becoming too out-of-date) and also giving us all the usual benefits a distributed SCM provides. The repository also includes an integrated version of the table support as described in the Comments section above.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CmakeGccm32&diff=62621CmakeGccm322018-04-24T18:33:18Z<p>Brad.king: Remove leading space rectangles from preformatted blocks</p>
<hr />
<div>= How to use gcc-multilib to cross compile software for Linux =<br />
<br />
Goal: compile a 32bits exe on running amd64 linux system.<br />
<br />
== Install the gcc-multilib package ==<br />
<br />
<pre><br />
$ sudo apt-get install gcc-multilib<br />
</pre><br />
<br />
== Write a CMake toolchain file ==<br />
<br />
For CMake to be able to crosscompile software, it requires you to write a toolchain file, which tells CMake<br />
some information about the toolchain.<br />
With the examples used above it will look like:<br />
<pre><br />
# the name of the target operating system<br />
SET(CMAKE_SYSTEM_NAME Linux)<br />
<br />
# which compilers to use for C and C++<br />
SET(CMAKE_C_COMPILER gcc)<br />
SET(CMAKE_C_FLAGS -m32)<br />
SET(CMAKE_CXX_COMPILER g++)<br />
SET(CMAKE_CXX_FLAGS -m32)<br />
<br />
# here is the target environment located<br />
SET(CMAKE_FIND_ROOT_PATH /usr/i486-linux-gnu )<br />
<br />
# adjust the default behaviour of the FIND_XXX() commands:<br />
# search headers and libraries in the target environment, search <br />
# programs in the host environment<br />
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)<br />
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)<br />
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)<br />
</pre><br />
<br />
Save this file as Toolchain-gcc-m32.cmake to some location where you will put<br />
all your toolchain files, e.g. $HOME.<br />
As you can see CMAKE_FIND_ROOT_PATH is set to /usr/i486-linux-gnu, which contains the libraries '''and''' headers <br />
installed with the toolchain.<br />
<br />
== Build the software for Linux ==<br />
<br />
Let's say you have the classical hello world software with a CMake based buildsystem and want to build this for Linux<br />
using gcc -m32.<br />
main.c:<br />
<pre><br />
#include <stdio.h><br />
<br />
int main()<br />
{<br />
printf("Hello world\n");<br />
return 0;<br />
}<br />
</pre><br />
<br />
CMakeLists.txt:<br />
<pre><br />
ADD_EXECUTABLE(hello main.c)<br />
</pre><br />
<br />
Then run CMake on it to generate the buildfiles, the important point is that you tell it to use the toolchain file you just wrote:<br />
<pre><br />
~/src/helloworld/ $ mkdir build<br />
~/src/helloworld/ $ cd build<br />
~/src/helloworld/build/ $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-gcc-m32.cmake -DCMAKE_INSTALL_PREFIX=/home/mathieu/gcc-m32-install .. <br />
-- Configuring done<br />
-- Generating done<br />
-- Build files have been written to: /home/mathieu/src/helloworld/build<br />
~/src/helloworld/build/ $ make<br />
Scanning dependencies of target hello<br />
[100%] Building C object CMakeFiles/hello.dir/main.o<br />
Linking C executable hello<br />
[100%] Built target hello<br />
</pre><br />
<br />
You can then verify:<br />
<br />
<pre><br />
$ file hello<br />
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped<br />
</pre><br />
<br />
In case you have a more complex application that is using let say zlib, you would need first to install it:<br />
<br />
<pre><br />
$ apt-cross --arch i386 -i zlib1g-dev<br />
</pre><br />
<br />
And after compilation, you can check that you are indeed using this zlib and not your system one:<br />
<br />
<pre><br />
$ ldd ./myapp<br />
...<br />
libz.so.1 => /usr/i486-linux-gnu/lib/libz.so.1 (0xf7b6b000)<br />
...<br />
</pre><br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CTest:Using_CTEST_and_CDASH_without_CMAKE&diff=62620CTest:Using CTEST and CDASH without CMAKE2018-04-24T18:33:18Z<p>Brad.king: Remove leading space rectangles from preformatted blocks</p>
<hr />
<div>This is a short tutorial, which shows how to use CTest scripts to populate a CDash dashboard. It shows how to checkout, configure, compile and test a project with CTest when not using CMake.<br />
<br />
As this tutorial is the outcome of a test setup, put together form many different sources, it will and can not be complete. It will only give an '''good''' overview. Detailed information can be found on the linked wiki pages or the CTest manual ( <span style="font-family:monospace;font-weight:bold;">$ man ctest</span> ).<br />
<br />
== Pre-requirements for the example setup ==<br />
* Project is under subversion control<br />
* No CTest files shall be stored in the project repository<br />
* Use of the autotools build system<br />
<br />
== Setup files ==<br />
A set of file is needed to form a complete system.<br />
<br />
* [[#steer.cmake|steer.cmake]]<br />
* [[#CTestConfig.cmake|CTestConfig.cmake]]<br />
* [[#CTestCustom.cmake|CTestCustom.cmake]]<br />
* [[#CTestTestfile.cmake|CTestTestfile.cmake]]<br />
<br />
== steer.cmake ==<br />
The steering script. It can be evoked from the command-line or via scheduled tasks for automatic running.<br />
<br />
=== Execute script ===<br />
<pre><br />
$ ctest -S steer.cmake<br />
</pre><br />
<br />
* use <span style="font-family:monospace;font-weight:bold;">-VV</span> for extra verbosity during debugging <br />
* see also [[CMake_Scripting_Of_CTest#Advanced_Settings|here]] for the usage of command line arguments.<br />
<br />
=== Example ===<br />
<br />
The example below intends to be a realistic usecase showing non-trivial usage. All code in this paragraph should be in one file. It is "broken up" only for the purpose of explanation.<br />
<br />
==== The first step is the retrieval of the build environment ====<br />
<br />
'''Get the hostname of current machine'''<br />
<pre><br />
find_program(HOSTNAME_CMD NAMES hostname)<br />
exec_program(${HOSTNAME_CMD} ARGS OUTPUT_VARIABLE HOSTNAME)<br />
set(CTEST_SITE "${HOSTNAME}")<br />
</pre><br />
Finds the paths to the program hostname, executes it, stores the result in ${HOSTNAME}. Then the ''CTEST_SITE'' variable is set, to be used in CDash.<br />
<br />
'''Get the system information of current machine'''<br />
<pre><br />
find_program(UNAME NAMES uname)<br />
macro(getuname name flag)<br />
exec_program("${UNAME}" ARGS "${flag}" OUTPUT_VARIABLE "${name}")<br />
endmacro(getuname)<br />
</pre><br />
Defines the macro getuname, for easy usage of ''uname''<br />
<br />
<pre><br />
getuname(osname -s)<br />
getuname(osrel -r)<br />
getuname(cpu -m)<br />
set(CTEST_BUILD_NAME "${osname}-${cpu}-prod")<br />
</pre><br />
Sets the build name, to be used in CDash.<br />
<br />
'''Get necessary executables'''<br />
<br />
The CTest command for svn (subversion) is found and set here:<br />
<pre><br />
find_program(CTEST_SVN_COMMAND NAMES svn)<br />
</pre><br />
<br />
This finds and sets the full path to the executable for make here:<br />
<pre><br />
find_program(MAKE NAMES make)<br />
</pre><br />
<br />
==== The build specific environment for the project ====<br />
<br />
<pre><br />
set(MODEL analysis)<br />
</pre><br />
Choose the dashboard group to be filled with this script. Not only the standard build groups (Experimental, Continous, Nighlty) can be chosen, but also [[CDash:Administration#Build_Groups|build groups]] which can be defined in CDash.<br />
<br />
<pre><br />
set(CTEST_DASHBOARD_ROOT "$ENV{HOME}/automatedBuild")<br />
set(CTEST_SOURCE_DIRECTORY "${CTEST_DASHBOARD_ROOT}/src")<br />
set(CTEST_BINARY_DIRECTORY "${CTEST_SOURCE_DIRECTORY}/build-${CTEST_BUILD_NAME}")<br />
</pre><br />
Set the source and binary directories of your project.<br />
<br />
==== Commands for the execution of CTest ====<br />
<br />
For an initial checkout, the ''CTEST_CHECKOUT_COMMAND'' has to be set:<br />
<pre><br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_SVN_COMMAND} co http://myRepositoryServer.com/myRepository/trunk ${CTEST_SOURCE_DIRECTORY}")<br />
</pre><br />
<br />
The initial checkout is only done if you specify the update command <span style="font-family:monospace;font-weight:bold;">ctest_update(SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE res)</span> ( see further down), which needs also to be configured :<br />
<pre><br />
set(CTEST_UPDATE_COMMAND "${CTEST_SVN_COMMAND}")<br />
</pre><br />
<br />
If one wants to have a clean checkout every time, then the update column of the dashboard will always say 0. Because it was all checked out in the initial checkout and not in the update. However, if one uses the svn flag <span style="font-family:monospace;font-weight:bold;">-r</span> with ''yesterdays'' date for the initial checkout, the update columns will show the updates which have been done in the last day.<br />
<br />
The commands which are executed in ''ctest_configure'' and ''ctest build'' have to be specified. Both are executed in the binary directory.<br />
<pre><br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_SOURCE_DIRECTORY}/configure --enable-optimization=3 --disable-debug --enable-doc=mono")<br />
set(CTEST_BUILD_COMMAND "/usr/bin/make -j16")<br />
</pre><br />
<br />
==== Configure CTest ====<br />
If the CTest configuration files [[#CTestConfig.cmake|CTestConfig.cmake]], [[#CTestCustom.cmake|CTestCustom.cmake]] and [[#CTestTestfile.cmake|CTestTestfile.cmake]] should or can not be stored in the repository itself, then they can be copied there automatically by CTest.<br />
<br />
<pre><br />
configure_file($ENV{HOME}/CTestConfiguartion/CTestConfig.cmake ${CTEST_SOURCE_DIRECTORY}/CTestConfig.cmake)<br />
configure_file($ENV{HOME}/CTestConfiguartion/CTestCustom.cmake ${CTEST_BINARY_DIRECTORY}/CTestCustom.cmake)<br />
configure_file($ENV{HOME}/CTestConfiguartion/CTestTestfile.cmake ${CTEST_BINARY_DIRECTORY}/CTestTestfile.cmake)<br />
</pre><br />
* ''CTestConfig.cmake'' should be put in the source directory<br />
* ''CTestCustom.cmake'' and ''CTestTestfile.cmake'' should be put in the binary directory<br />
* Full paths should be given<br />
<br />
Then the custom configuration has to be read in.<br />
<pre><br />
ctest_read_custom_files("${CTEST_BINARY_DIRECTORY}")<br />
</pre><br />
<br />
==== General CTest settings ====<br />
<br />
<pre><br />
set(CTEST_TIMEOUT "7200")<br />
</pre><br />
Sets the timeout value for this script in seconds. Here 120 min.<br />
<br />
<pre><br />
set( $ENV{LC_MESSAGES} "en_EN" )<br />
</pre><br />
Set the output language to english, so that CTest can analyze it.<br />
<br />
==== Run CTest ====<br />
<br />
'''Start'''<br />
<br />
<pre><br />
ctest_start(${MODEL} TRACK ${MODEL} )<br />
</pre><br />
Starts CTest and assigns the build track to be filled. It creates automatically the binary directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}</span>, if not present. Furthermore also the directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}/Testing</span> is created, where all the result and log files are stored.<br />
<br />
'''Update / Initial checkout'''<br />
<br />
<pre><br />
ctest_update( SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Performs the update from the repository. As the <span style="font-family:monospace;font-weight:bold;">CTEST_CHECKOUT_COMMAND</span> is set here, also the initial checkout done.<br />
<br />
'''Configure build system'''<br />
<br />
The ''autoreconf'' command of the autotools package is not supported by standard CTest, so the process has to be called manually.<br />
<pre><br />
execute_process(COMMAND "/usr/bin/autoreconf" "-f" "-i" WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY} RESULT_VARIABLE autoreconfResult<br />
OUTPUT_VARIABLE autoreconfLog ERROR_VARIABLE autoreconfLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/autoreconf.log "${autoreconfLog}")<br />
</pre><br />
Runs the ''autoreconf'' command stores both stdout and stderr in a log file.<br />
<br />
In order to execute the configure/build block only if ''autoreconf'' succeeded, they can be put into an if statement<br />
<pre><br />
if( NOT ${autoreconfResult} )<br />
... the other build commands ...<br />
endif( NOT ${autoreconfResult} )<br />
</pre><br />
<br />
'''Configure / Build block'''<br />
<br />
<pre><br />
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Configures the project. It is executed in the binary directory.<br />
<br />
<pre><br />
ctest_build( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Builds the project. It is executed in the binary directory.<br />
<br />
<pre><br />
execute_process(COMMAND "/usr/bin/make install -j 16" "-f" "-i" WORKING_DIRECTORY ${CTEST_BINARY_DIRECTORY} <br />
RESULT_VARIABLE makeInstallResult OUTPUT_VARIABLE makeInstallLog ERROR_VARIABLE makeInstallLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/makeinstall.log "${makeInstallLog}")<br />
</pre><br />
Like the ''autoreconf'' command, the install command is not part of the standard test. It has to be invoked manually.<br />
Both stdout and stderr are written into a log file.<br />
<br />
'''Launch tests'''<br />
<br />
<pre><br />
ctest_test( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
Invokes all tests, defined in [[#CTestTestfile.cmake|CTestTestfile.cmake]]<br />
<br />
==== Finialize the submission ====<br />
After the all build steps, the results have to be submitted to CDash via<br />
<pre><br />
ctest_submit( RETURN_VALUE res)<br />
</pre><br />
This uses the settings of [[#CTestConfig.cmake|CTestConfig.cmake]].<br />
<br />
==== Complete Example ====<br />
The complete example '''steer.cmake''' could look like this :<br />
<br />
<pre><br />
# ----------------------------------------------------------- <br />
# -- Get environment<br />
# ----------------------------------------------------------- <br />
<br />
## -- Set hostname<br />
## --------------------------<br />
find_program(HOSTNAME_CMD NAMES hostname)<br />
exec_program(${HOSTNAME_CMD} ARGS OUTPUT_VARIABLE HOSTNAME)<br />
<br />
set(CTEST_SITE "${HOSTNAME}")<br />
<br />
## -- Set site / build name<br />
## --------------------------<br />
<br />
find_program(UNAME NAMES uname)<br />
macro(getuname name flag)<br />
exec_program("${UNAME}" ARGS "${flag}" OUTPUT_VARIABLE "${name}")<br />
endmacro(getuname)<br />
<br />
getuname(osname -s)<br />
getuname(osrel -r)<br />
getuname(cpu -m)<br />
<br />
set(CTEST_BUILD_NAME "${osname}-${cpu}-prod")<br />
<br />
## -- SVN command<br />
## ----------------<br />
find_program(CTEST_SVN_COMMAND NAMES svn)<br />
<br />
## -- make command<br />
## -----------------<br />
find_program(MAKE NAMES make)<br />
<br />
# ----------------------------------------------------------- <br />
# -- build specific<br />
# ----------------------------------------------------------- <br />
<br />
set(MODEL "analysis")<br />
<br />
## -- DashBoard Root<br />
set(CTEST_DASHBOARD_ROOT "$ENV{HOME}/automatedBuild")<br />
<br />
## -- SRC Dir<br />
set(CTEST_SOURCE_DIRECTORY "${CTEST_DASHBOARD_ROOT}/src")<br />
<br />
## -- BIN Dir <br />
set(CTEST_BINARY_DIRECTORY "${CTEST_SOURCE_DIRECTORY}/build-${CTEST_BUILD_NAME}")<br />
<br />
## -- Build options<br />
set(OPTION_BUILD "-j16")<br />
<br />
# ----------------------------------------------------------- <br />
# -- commands<br />
# ----------------------------------------------------------- <br />
<br />
## -- Checkout command<br />
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
set(CTEST_CHECKOUT_COMMAND "${CTEST_SVN_COMMAND} co http://myRepositoryServer.com/myRepository/trunk ${CTEST_SOURCE_DIRECTORY}")<br />
endif(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")<br />
<br />
## -- Update Command<br />
set(CTEST_UPDATE_COMMAND "${CTEST_SVN_COMMAND}")<br />
<br />
## -- Configure Command<br />
set(CTEST_CONFIGURE_COMMAND "${CTEST_SOURCE_DIRECTORY}/configure configure --enable-optimization=3 --disable-debug --enable-doc=mono")<br />
<br />
## -- Build Command<br />
set(CTEST_BUILD_COMMAND "${MAKE} ${OPTION_BUILD}")<br />
<br />
# ----------------------------------------------------------- <br />
# -- Configure CTest<br />
# ----------------------------------------------------------- <br />
<br />
## -- CTest Config<br />
configure_file($ENV{HOME}/CTestConfiguration/CTestConfig.cmake ${CTEST_SOURCE_DIRECTORY}/CTestConfig.cmake)<br />
<br />
## -- CTest Custom<br />
configure_file($ENV{HOME}/CTestConfiguration/CTestCustom.cmake ${CTEST_BINARY_DIRECTORY}/CTestCustom.cmake)<br />
<br />
## -- CTest Testfile<br />
configure_file($ENV{HOME}/CTestConfiguration/CTestTestfile.cmake ${CTEST_BINARY_DIRECTORY}/CTestTestfile.cmake)<br />
<br />
## -- read CTestCustom.cmake file<br />
ctest_read_custom_files("${CTEST_BINARY_DIRECTORY}")<br />
<br />
# ----------------------------------------------------------- <br />
# -- Settings<br />
# ----------------------------------------------------------- <br />
<br />
## -- Process timeout in seconds<br />
set(CTEST_TIMEOUT "7200")<br />
<br />
## -- Set output to english<br />
set( $ENV{LC_MESSAGES} "en_EN" )<br />
<br />
# ----------------------------------------------------------- <br />
# -- Run CTest<br />
# ----------------------------------------------------------- <br />
<br />
## -- Start<br />
message(" -- Start dashboard ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_start(${MODEL} TRACK ${MODEL})<br />
<br />
## -- Update<br />
message(" -- Update ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_update( SOURCE "${CTEST_SOURCE_DIRECTORY}" RETURN_VALUE res)<br />
<br />
## -- Run autoreconf<br />
message(" -- Autoreconf ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
execute_process(COMMAND "/usr/bin/autoreconf" "-f" "-i" WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY} RESULT_VARIABLE autoreconfResult<br />
OUTPUT_VARIABLE autoreconfLog ERROR_VARIABLE autoreconfLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/autoreconf.log "${autoreconfLog}")<br />
<br />
if( NOT ${autoreconfResult} )<br />
<br />
## -- Configure <br />
message(" -- Configure ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_configure(BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
<br />
## -- BUILD<br />
message(" -- Build ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_build( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
<br />
## -- INSTALL<br />
message(" -- Install ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
execute_process(COMMAND "${MAKE} install ${OPTION_BUILD}" WORKING_DIRECTORY ${CTEST_BINARY_DIRECTORY} <br />
RESULT_VARIABLE makeInstallResult OUTPUT_VARIABLE makeInstallLog ERROR_VARIABLE makeInstallLog)<br />
file(WRITE ${CTEST_BINARY_DIRECTORY}/Testing/makeinstall.log "${makeInstallLog}")<br />
<br />
## -- TEST<br />
message(" -- Test ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_test( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
<br />
endif( NOT ${autoreconfResult} )<br />
<br />
## -- SUBMIT<br />
message(" -- Submit ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
ctest_submit( RETURN_VALUE res)<br />
<br />
message(" -- Finished ${MODEL} - ${CTEST_BUILD_NAME} --")<br />
</pre><br />
<br />
== CTestConfig.cmake ==<br />
This file sets the tranfer parameters that CTest will use when submitting to CDash.<br />
<pre><br />
ctest_submit( RETURN_VALUE res)<br />
</pre><br />
<br />
Several different ways exist to submit results to the dashboard like ''http'', ''ftp'', ''scp'' and ''XML-RPC''. However only the ''http'' case shall be discussed here.<br />
Details can be found an the [[CTest:Submission_Issues||CTest Submission Issues]] page.<br />
<br />
=== Example ===<br />
This file can be also downloaded from CDash after creating a new project.<br />
<br />
<pre><br />
set(CTEST_PROJECT_NAME "Test-Project")<br />
set(CTEST_NIGHTLY_START_TIME "01:00:00 CET")<br />
set(CTEST_DROP_METHOD "http")<br />
set(CTEST_DROP_SITE "myTestNode.myNetwork.com")<br />
set(CTEST_DROP_LOCATION "/cdash/submit.php?project=TestProject")<br />
set(CTEST_DROP_SITE_CDASH TRUE)<br />
</pre><br />
<br />
== CTestCustom.cmake ==<br />
This file is used to customize CTest. A detailed description of all options, can be found [[CMake_Testing_With_CTest#Customizing_CTest|here]]. <br />
In order to be read in properly this file has to be placed in the binary directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}</span>. <br />
<br />
It can also be read from any other location by specifying<br />
<pre><br />
ctest_read_custom_files("<PATH TO CTestCustom.cmake FILE>")<br />
</pre><br />
<br />
=== Examples ===<br />
This are only some examples of customization. The full list and detailed description can be found [[CMake_Testing_With_CTest#Customizing_CTest|here]].<br />
<br />
* Change the maximum numbers of warnings<br />
<pre><br />
set(CTEST_CUSTOM_MAXIMUM_NUMBER_OF_WARNINGS "500" )<br />
</pre><br />
<br />
* Change the maximum numbers of errors<br />
<pre><br />
set(CTEST_CUSTOM_MAXIMUM_NUMBER_OF_ERRORS "200" )<br />
</pre><br />
<br />
* Add ''fake warnings'' to a list of exceptions<br />
<pre><br />
set(CTEST_CUSTOM_WARNING_EXCEPTION<br />
${CTEST_CUSTOM_WARNING_EXCEPTION}<br />
<br />
# -- doxygen warnings<br />
"are not documented:"<br />
"Skipping documentation"<br />
)<br />
</pre><br />
Every regular expression can be added as exception.<br />
<br />
== CTestTestfile.cmake ==<br />
This file specifies the test which should be executed in<br />
<pre><br />
ctest_test( BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE res)<br />
</pre><br />
<br />
The file should be placed in the binary directory <span style="font-family:monospace;font-weight:bold;">${CTEST_BINARY_DIRECTORY}</span>.<br />
<br />
=== Examples ===<br />
Each test consists of:<br />
* The unique name of the test ( eg.: <span style="font-family:monospace;font-weight:bold;">testname1</span> )<br />
* The full path to the executable of the test ( eg.: <span style="font-family:monospace;font-weight:bold;">"$ENV{HOME}/bin/TEST_EXECUTABLE_1.sh"</span> )<br />
* A List of arguments to the executable ( eg.: <span style="font-family:monospace;font-weight:bold;">"ARGUMENT_1"</span> <span style="font-family:monospace;font-weight:bold;">"ARGUMENT_2"</span> etc. )<br />
<br />
<pre><br />
ADD_TEST(testname1 "$ENV{HOME}/bin/TEST_EXECUTABLE_1.sh" "ARGUMENT_1")<br />
ADD_TEST(testname2 "$ENV{HOME}/bin/TEST_EXECUTABLE_2.sh")<br />
</pre><br />
<br />
{{CMake/Template/Footer}}</div>Brad.kinghttps://public.kitware.com/Wiki/index.php?title=CTest:TestWithoutBuild&diff=62619CTest:TestWithoutBuild2018-04-24T18:33:17Z<p>Brad.king: Remove leading space rectangles from preformatted blocks</p>
<hr />
<div>== Carrying out tests on a machine without building first ==<br />
<br />
This page describes, what can be done to perform tests on a different machine than the one<br />
where the software was built.<br />
<br />
I created an installer image (BitRock installer in our case) containing<br />
the normal deliverables of our software plus the following items:<br />
* Some scripts needed to carry out our tests. This also contains software needed to carry out the tests (Squish)<br />
* A complete CMake installation<br />
* The following CMake-generated files from the build directory:<br />
** CTestCustom.cmake<br />
** DartConfiguration.tcl<br />
** CTestTestfile.cmake<br />
* Post-installation script<br />
<br />
The last item is a script, which is run by the installer as a post-install step. This script adjusts<br />
all paths in the above CMake files from the build directory to the installation directory. It also adjusts the<br />
host name contained in DartConfiguration.tcl, so the results show up in CDash under the correct name.<br />
The final step of the post-installation script is to call ctest with the following arguments:<br />
<pre><br />
ctest -T Test -T Submit --track Nightly<br />
</pre><br />
For this to work the environment variable CMAKE_ROOT is set to the just-installed CMake share directory in the script.<br />
<br />
This causes a simple installation, which can be done automatically via cron or the Windows task planner, to perform<br />
the installation, carry out the tests and submit the results to CDash.The only requirement for the test machines<br />
is to have standard software installed, we need perl and python for our tests.<br />
<br />
{{CMake/Template/Footer}}</div>Brad.king