I'm linking to FLTK in my project using CMake and want to make sure that if anyone else tries to do so on their machine that they have the latest version (1.3.7).
The normal way in CMake to do this is
find_package(FLTK 1.3.7 REQUIRED)
However this requires variables like PACKAGE_FIND_VERSION_MAJOR etc. to be set in the relevant FLTKConfig.cmake file. Unfortunately, these are not set in this package, but what has been set is set (FLTK_VERSION 1.3.7)
How can I test that this variable (it might be set to 1.3.6 or 1.4.0 or whatever) is greater or equal to 1.3.7 in my CMakeLists.txt file?
The if command supports VERSION keyword to perform version numbers comparison:
if(${FLTK_VERSION} VERSION_GREATER_EQUAL 1.3.7)
Related
when using pkg-config in CMake through the find_package(PkgConfig) if I have multiple versions of the same library in different locations, the command stops at the first (wrong) one if I ask for a specific version, instead of searching along the other paths in the $PKG_CONFIG_PATH variable.
For instance, if my $PKG_CONFIG_PATH is /opt/lib/pkgconfig:/usr/local/lib/pkgconfig and I have Eigen 3.2.6 installed in /opt/lib/pkgconfig and Eigen 3.2.10 in /usr/local/lib/pkgconfig
then if I do:
find_package(PkgConfig)
pkg_check_modules(EIGEN eigen3=3.2.10 REQUIRED)
cmake stops with an error because it finds Eigen 3.2.6 first.
How to solve this?
Thanks.
I'm using Yocto and struggling to update cmake. The poky version that we are using provides cmake version 3.3.1, but one of the packages that I'm building requires cmake version 3.5 or greater.
Looking at the poky git repo, the latest provides version 3.8.2. I figured that the easiest way to upgrade cmake was to include the recipes for cmake from the current poky master branch within my own meta repo, in order to override the lesser version. So I copied the cmake directory, and expected the build to continue along...
Unfortunately, the cmake recipes that I copied in aren't working. The recipes won't even load, as they throw an error, saying "docker must contain prefix as its prefix." Printing the output of the prefix and docdir variables to the console, I see that docdir is set to "${datadir}/doc" -- the datadir variable is not expanded.
In summary, the questions that I have are:
What is the best way to upgrade cmake? Is the best way to copy in the updated recipes into my own meta repo?
Why isn't the datadir variable being expanded, and how can I fix that?
What is probably happening is that the recipe for cmake 3.8.2 (2.4) is not backward compatible with the poky version from 3.3.1 (Version 1.9). The reference is here. I guess some refactoring and important milestones happened meanwhile
The easiest way is to upgrade the whole poky folder in your ecosystem, hoping it is not breaking your other recipes.
Edit: The accepted answer actually shows that it is pretty normally possible to set CMAKE_MODULE_PATH as any other CMake variable e.g. via the -DCMAKE_MODULE_PATH path CLI parameter. It seems that in my case there is some included CMake script that calls set(CMAKE_MODULE_PATH /library_path), which erases all previous paths set to the variable. That's why I couldn't get the variable to do what I wanted it to do. I'll leave the question here in case anybody else faces this kind of situation.
I'm building a (3rd party) project that uses the Protobuf library (but this question is general). My system has a system-wide install of a newer version of Protobuf than the project is compatible with. So I've downloaded and compiled from source an older version of Protobuf.
The project uses CMake, and in its CMakeLists.txt, there is:
find_package(Protobuf REQUIRED)
Which, however, finds the (incompatible) system install. Of course, CMake doesn't know about my custom build of Protobuf. But how do I tell it?
I've created a FindProtobuf.cmake file in, say, ~/usr/share/cmake-3.0/Modules/ and want the build process to use this one for finding Protobuf. But I haven't succeeded forcing CMake to pick up this one and not the system one. I think the reason is quite obvious from the CMake docs of find_package:
The command has two modes by which it searches for packages: “Module” mode and “Config” mode. Module mode is available when the command is invoked with the above reduced signature. CMake searches for a file called Find<package>.cmake in the CMAKE_MODULE_PATH followed by the CMake installation. If the file is found, it is read and processed by CMake. ... If no module is found and the MODULE option is not given the command proceeds to Config mode.
So until I succeed to change CMAKE_MODULE_PATH, CMake will just pick up the FindProtobuf.cmake installed to the default system path and won't ever proceed to the "Config" mode where I could probably make use of CMAKE_PREFIX_PATH.
It's important for me to not edit the CMakeLists.txt since it belongs to a 3rd party project I don't maintain.
What I've tried (all without success):
calling CMAKE_MODULE_PATH=~/usr/share/cmake-3.0/Modules cmake ... (the env. variable is not "transferred" to the CMake variable with the same name)
calling cmake -DCMAKE_MODULE_PATH=~/usr/share/cmake-3.0/Modules ... (doesn't work, probably by design?)
calling Protobuf_DIR=path/to/my/protobuf cmake ... (the project doesn't support this kind of override for Protobuf)
It seems to me that, unfortunately, the only way to alter the CMAKE_MODULE_PATH used by find_package is to alter it from within CMakeLists.txt, which is exactly what I want to avoid.
Do you have any ideas/workarounds on how not to touch the CMakeLists.txt and still convince find_package to find my custom Protobuf?
For reference, the CMake part of this project is on github .
As a direct answer to your question, yes, you can set CMAKE_MODULE_PATH at the command line by running cmake -DCMAKE_MODULE_PATH=/some/path -S /path/to/src -B /path/to/build.
But that probably doesn't do what you want it to do; see below.
The Bitbucket link you supplied is dead, but here are a few suggestions that might help.
Avoid writing your own find modules, especially when the upstream supplies CMake config modules.
You can direct CMake to your custom Protobuf installation by setting one of CMAKE_PREFIX_PATH or Protobuf_ROOT (v3.12+) to the Protobuf install root.
You can tell find_package to try CONFIG mode first by setting CMAKE_FIND_PACKAGE_PREFER_CONFIG to true (v3.15+). Then set Protobuf_DIR to the directory containing ProtobufConfig.cmake.
Failing all else, you can manually set the variables documented in CMake's own FindProtobuf module, here: https://cmake.org/cmake/help/latest/module/FindProtobuf.html
All these variables can be set at the configure command line with the -D flag.
There are very few environment variables that populate CMake variables to start and I would avoid relying on them. There is an exhaustive list here: https://cmake.org/cmake/help/latest/manual/cmake-env-variables.7.html. CMAKE_MODULE_PATH is not among them.
I am working on a project that uses CMake. The top CMakeLists.txt file contains the following line:
cmake_minimum_required(VERSION 3.7.2) # Kittens will die if you switch to an earlier version of CMake. We suggest using CMake 3.8.0.
I want to force all developers to switch to CMake 3.8.0, but for some reasons, not all developers have administration rights and are not able to switch from 3.7.2 to 3.8.0 immediately. Actually, we do not need any new features of version 3.8.0, but our policy is to use always the newest and greatest tools to prevent "porting up" problems in the future - for instance switching fast from Qt4 to Qt5 was a good decission in the past - I know switching always to the newest libraries and tools has also some drawbacks as discussed here, but we want to do it this way.
Because of this, instead of forcing everyone to use version 3.8.0, I'd like to output a warning message if CMake 3.7.2 is used. Somehow like this:
# not working - just pseudocode
if(CMAKE_VERSION == "3.7.2")
message("Please consider to switch to CMake 3.8.0")
endif()
I tried to read the VERSION variable, but this does not work. Does anyone now how this check can be achieved?
There exist a few variables for that, described here:
CMAKE_MAJOR_VERSION
major version number for CMake, e.g. the "2" in CMake 2.4.3
CMAKE_MINOR_VERSION
minor version number for CMake, e.g. the "4" in CMake 2.4.3
CMAKE_PATCH_VERSION
patch version number for CMake, e.g. the "3" in CMake 2.4.3
Also, the variable CMAKE_VERSION contains the string for the version.
In your case, you would, for instance, use the following:
if(${CMAKE_VERSION} VERSION_LESS "3.8.0")
message("Please consider to switch to CMake 3.8.0")
endif()
Other comparison operators are VERSION_EQUAL and VERSION_GREATER.
Am using ubuntu 16 which seems automatically linking against Eigen version 3.2.92 located at /usr/include/Eigen3. I would like to link against version 3.2.0. Thus my questions is
How could I get Eigen version 3.2.0? It is not clear from Eigen website
What I did so far is just copying /usr/include/Eigen3 from an ubuntu 14 machine, since the latter automatically comes with version 3.2.0
How to link against it using CMake?
Tried
SET (EIGEN3_INCLUDE_DIR "/home/usr/mylib/eigen/eigen3/Eigen") but without success.
For info, am using ROS (Kinetic) catkin. It happens that catkin somehow forces the development packages to linking/compiling against packages installed by default (/usr/include/..)
Other versions of Eigen are available on the website or better, from the hg repo.
How is the EIGEN3_INCLUDE_DIR used in your cmake file? For example, in one of my projects, we have set(EIGEN_INCLUDE_DIR ${SOURCE_DIR}/Common). Note that it doesn't have the "3" (it's just a variable name) and that it doesn't include the last "/Eigen" in the path.
First of all, Eigen is a header-only library, so you are not linking against it :-) Instead you want to use specific header files.
For your own packages, you can use include_directories(SYSTEM ${EIGEN3_INCLUDE_DIR}, assuming you set EIGEN3_INCLUDE_DIR correspondingly to the version you want to use. Beware that if that version differs too much (e.g. 2.x vs 3.x) with versions used by interfaces (e.g. tf library?), this may cause some issues if datatypes changed. You also need to make sure that no other directive overwrites that - best to check the parameters to g++ for that.