Adhering to the best practice for modern CMake I want to use this command instead of flags or set-based commands. However, I cant seem to make it work, since I cannot find associated commands for the newly introduced C++17 features. For C++14 I can do something along the following lines
target_compile_features(Foo
PUBLIC
cxx_strong_enums
PRIVATE
cxx_lambdas
)
I guess what I am asking is, what is the proper way to enable the latest standard of C++ in cmake without resorting back to legacy cmake
You're going in the right direction, you may just need to update your CMake version.
It started with CMake Version 3.8:
The Compile Features functionality is now aware of C++ 17. No specific features are yet enumerated besides the cxx_std_17 meta-feature.
For VS you need e.g. at least CMake Version 3.10.
References
How to enable /std:c++17 in VS2017 with CMake
ccmake using cmake version 3.10
Related
Suppose that:
I'm writing a C or C++ library.
I intend my library to be usable on multiple Unix-like platforms (and perhaps also on Windows).
I use CMake for build configuration.
I have some dependencies on other libraries.
Given this - should I be cognizant of the pkg-config mechanism? Versed in its use? Or - should I just ignore it? I'm asking both about its use when configuring my library's build, but also about whether to make sure the installation commands generate and install a .pc file for my library?
Is there a convenient way to find what the minimum compatible CMake version should be (besides testing it with every single version)? I'm looking for a tool that will parse my CMakeLists.txt, find all the features I'm using, look up the CMake version they were added, and spit out the maximum. A quick look though cmake --help didn't show an option to do this. Is there an external tool that will do this for me?
As of now, there is no such tool. This is because there are a number of problems with creating such a tool.
Most importantly is that CMake has never made any promises of forwards-compatibility. Listfiles authored with a newer version of CMake have never been guaranteed to work with older versions, regardless what cmake_minimum_required setting appears. This is due to several factors: new features added, improved logic in Find modules and compiler detection, and so on. Basically anything that doesn't break old code, but makes newer code more intelligent and robust, even without source changes.
Thus, a tool that only checked for new features (like generator expressions) would miss out on changes to other parts of the overall system.
This means any such tool would have to model CMake so closely that it would be easier to simply automate running an old CMake version and testing the build. If you feel you need to do this, you should automate it yourself.
Taking a step back, CMake is amazingly, ludicrously easy to upgrade and you can save yourself and others a lot of backwards compatibility headaches like this by simply sidestepping the issue. Use a recent version, declare it as a minimum and encourage your users to upgrade. On Linux, Kitware provides statically linked executables for x86 and arm that require nothing besides libc. I have never heard of these executables not working. I use them on old Raspberry Pis. I have yet to see any remotely valid reason to support versions of CMake older than a year or so.
I have an embedded project for ARM platform, specifically aarch64.
Up until now I was using Make. I recently set up CMake with no particular issues.
I moved to CMake because I was under the impression it was a more modern build tool that would have allowed a smarter configuration.
For example, I can compile my project using different toolchains (aarch64-elf-gcc-linaro, aarch64-linux-gnu-gcc,...) and I would like CMake to try if any of those are installed on the system and use whichever is found first by default.
Is this possible (or meant to)? I'd expect it to be an easy feat for the tool, but after searching for a while I can't seem to find the right track.
Yes, you can make your CMake project to search for available tool-chains installed in your OS, choose one and compile your project. I also write a CMake program for ARM embedded project, because now it is universal transferable between different OS system Windows and Unix. On Linux there is ARM ToolChain installed and on Windows there is Keil-MDK. If you have different tool-chains to choose between, you can write CMake script which will find paths with command like find_path() and then call correct "toolchianxx.cmake" script with right compiler flags for chosen compiler.
In your particular problem just use find_path commands and use hits to find installed compilers in "pre-set" known paths.
From a set of CMakeLists.txt files, how can I determine an appropriate version number for cmake_minimum_required()? Is there a better way than being familiar with the history of CMake features and using trial and error?
CMake has per-version documentation on its website. Using it, you may check that all features you use in your project are supported by a specific CMake version.
Features include command names, command options and their possible values, names of modules shipped with CMake.
Usually project does not need precise minimum CMake version. You may take reasonable version, which is accessible for users, and check whether this version supports all features you use.
I'm currently investigating cmake to allow automatic building on the Win32 platform. For all runtimes and libraries I'd like to build, Visual Studio (2008/2010) projects do allready exist.
I've come across cmake, but I'm unsure if I really need it. As the documentation says, cmake generates VS projects and they then can be built e.g. using MSBuild.
As the projects itself allready do exist (and build nicely via the IDE or MSBuild on the cmd line), what do I need and use cmake for? Just for directory/project folder traversal? Build failure reporting?
Regards,
Paul
Well, strictly speaking you do not need it. However, it does give you a few advantages:
The idiomatic way to use CMake, forces you to use out-of-source builds. Arguable, but I am personally convinced that these keep you source-repository very clean.
You can support multiple visual studio versions (with the out-of-source builds). Perhaps it will be a little easier to port your project to other compilers (from MinGW -> Linux GCC).
With the find_package and config.cmake files, and a large number of available findXXX modules, CMake makes it a lot easier to "import" third-party libraries into your build-chain.
You don't need it. Cmake is only useful if you are trying to keep the same source code able to build in multiple platforms and compilers. If you are simply building using the microsoft stack you have no need of it.