Is there a way to quickly scaffold a basic C++ CMake project using CMake itself? For examples in an empty directory calling cmake new then CMake asks a few questions e.g. project name, lisence and generator. Then CMake generates all the required files and directories, e.g. CMakeLists.txt file, src directory and probably initialize it as Git repository.
I don't know of such features and I don't see a point to add scaffolding into CMake itself. There are free and popular tools specifically for scaffolding purpose, so I suggest you to go to yeoman or slush generators search pages and search for cmake.
You may write a CMake function to create an empty project with a specific layout.
file command helps you to create files and directories.
Related
I have a CMake project. It is a crossplatform project developed by a team of developers. Visual Studio and other make files are inside version control for library release and external developers.
Each time a file is added we need to recompile all project files for all platforms. How do I force CMake to generate new project files for all systems at once (if possible from inside CMakeLists.txt, not as command line arguments)?
I think it doesn't make sense for this to be possible within the CMakeLists.txt file. CMake is a makefile generator. Everything in the CMakeLists.txt file is configuring the makefile, and it can also be repurposed to make project files.
If the CMakeLists.txt file could also request to generate a different kind of makefile... it would be different from every other command in the CMakeLists.txt file in that it isn't describing the currently selected makefile.
If I were you I would just make a shell script, or a simple makefile, separate from CMake, which rebuilds each of the project files, by invoking CMake from command line with appropriate parameters.
Is the goal of the versioned CMake produced build scripts to not force developers to install CMake?
In any case: it's best to use the right tool for the right job. CMake is for producing build-files and the little scripting necessary to do so. Use a scripting environment (Bash, cmd.exe) to run CMake as necessary for all your platforms.
This keeps the CMake files clean (and readable, CMake scripting is hard to read) and provides clean separation of concerns.
I have a CMAKE project that depends on other projects built with CMAKE. These are : glfw, oglplus, portaudio etc.
How should I set up my project to work well in a cross platform fashion? What is the recommended way to go about it? I have been trying to read the CMAKE documentation but could only find examples to simple scenarios.
Just add the dependencies to your project README and expect the user stored them (already compiled) in system scope.
Add CMake options to request the path to dependency files.
Use add_subdirectory to chain your project with dependencies.
I'm writing an application that relies on the Poco project. I just need a few sub modules but they use macros defined by the Poco project which are stored in a cmake folder at the root of the Poco folder structure.
I don't want to drag the whole Poco folder as I don't want to link my project to the whole Poco framework. How can I make those macros available to my project?
I'm not sure to well understand what you need. But why not simply include de file containing the macros by this way with cmake ?
include(path/to/Poco/cmake/macros.cmake)
Take the Poco project
Open the main CMakeLists.txt of Poco and comment (with #) all the add_subdirectory commands for the directories you don't need.
Try to build Poco
If it fails, add back the directories which contains the missing dependencies (in short, you might think you don't need a directory, but it might be that one of the directories you need depends on another directory)
When it builds, you can delete all the directories for which you have removed the command add_subdirectory
I'm developing a lib and now trying to make it usable through cmake find_package keyword.
Using the config mode works fine.
I've put the CPackConfig.cmake generated by cmake inside the installation folder of my lib by naming it log++Config.cmake and it can be found in my project. Fine.
But this method is not satisfying. I need to define my own variables such as lib dependencies needed to link and some custom macros, and didn't found any way to embed this inside the CPackConfig.cmake.
So now I'm trying to use the module mode of find_package. My concern is that I can't find any way to have cmake use my Findlog++.cmake without putting it inside cmake installation folders (which is awfully ugly).
I've found some posts telling to just put this file inside my project root but it's almost as ugly as modifying cmake itself.
Is there a way to have my Findlog++.cmake file somewhere inside my lib folder and have cmake finding it without setting the CMAKE_MODULE_PATH variable?
You seem to be confused between CPack and 'config file packages'. First, understand that they are separate and different. Then read
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html
to learn about usage requirements and inclusion of macros etc.
Is there any way to create a FindXXX.cmake automatically where XXX is my Cmake project? I see many projects that they created their FindXXX.cmake manually but I believe it's possible to create it automatically.
And, where I should install my project on Linux?
Thanks!
Take a look at CMake's project config file mechanism (along with the CMakePackageConfigHelper module; you might also want to take a look at this wiki page).
Find scripts are most useful for locating dependencies that are not aware of CMake themselves. If on the other hand the dependency was also built using CMake, you can let CMake auto-generate a project config file for you as part of that project's build process. This config file will allow you to refer to the targets of that project from an enclosing project as if they were being built as part of the enclosing project's CMake run. This is even more powerful than using find scripts, as it allows for example distinct handling of configurations beyond the debug/optimized options available to traditional find scripts.
On Windows, projects generating config files this way will register themselves with CMake, so that depending projects building on the same machine can find them automatically without any additional configuration. If you are building on non-Windows platforms (or you are building the two libraries on different machines) you will have to place the config file in a default directory (the docs for find_package describe which directories are searched) or explicitly point CMake to the location using CMAKE_MODULE_PATH.
Modern CMake-aware libraries should always prefer this approach over traditional find scripts. A prominent example of a library that does this already is Qt5.
CMake supports templating with configure_file() command.
Standard dirs where CMake searches for FindXXX.cmake modules are listed in the documentation of find_package() command.