My FindEigen.cmake is as follows:
find_path(EIGEN_INCLUDE_DIR NAMES Eigen/Core
PATHS
PATH_SUFFIXES eigen3
${CMAKE_CURRENT_SOURCE_DIR}/../../thirdparty
/usr/local/include
/usr/local/homebrew/include # Mac OS X
/opt/local/var/macports/software # Mac OS X
/opt/local/include
/usr/include)
# handle the QUIETLY and REQUIRED arguments and set EIGEN_FOUND to TRUE if
# all listed variables are TRUE
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(EIGEN DEFAULT_MSG EIGEN_INCLUDE_DIR)
This is called from my CMakeLists.txt file as follows:
find_package(Eigen REQUIRED)
The message I get back from the cmake gui is:
Could NOT find EIGEN (missing: EIGEN_INCLUDE_DIR)
but this is not an error and the configuration completes successfully. My understanding is that the REQUIRED option means that cmake should throw an error and halt if the package isn't found, and that the FIND_PACKAGE_HANDLE_STANDARD_ARGS method should enforce that. But this isn't happening for me. Any ideas why not?
I just had a similar problem which was caused by the different naming used for the Eigen library in find_package(Eigen REQUIRED) and find_package_handle_standard_args(EIGEN). E.g. you need to change EIGEN to Eigen.
Using the same naming in both places should fix this, along with the REQUIRED_VARS as suggested by #debris.
try using required_vars
FIND_PACKAGE_HANDLE_STANDARD_ARGS(EIGEN REQUIRED_VARS EIGEN_INCLUDE_DIR)
Related
In an attempt to create a cross-compilation CMake toolchain template with the SDCC compiler, I have come across a very weird issue.
As described in this link, if the toolchain.cmake file defines a CMAKE_SYSTEM_NAME, CMake will look for the file with the ${CMAKE_SYSTEM_NAME}.cmake under the Module/Platform directory. And this file should define platform-specific options. In my case, I am using it to find the sdcc compiler and setting some compiler flags.
This works just fine for me. Using cmake -DCMAKE_MODULE_PATH="${PATH_TO_MY_MODULES}" -DCMAKE_TOOLCHAIN_FILE="${PATH_TO_MY_TOOLCHAIN}" -DSDCC_SYSROOT="SOME_VALUE", CMake finds all the correct toolchain and platform files.
It seems like the toolchain and the platform file are executed (not sure if that's the correct term) a few times during the configuration process. In the first few times, the variable SDCC_SYSROOT I passed in the CMake command has the value SOME_VALUE as expected. However, the same variable SDCC_SYSROOT seems to lose the value in the last time these toolchain/platform files are executed. So they are empty. This causes my script to generate a fatal error.
toolchain.cmake has the following contents:
set(CMAKE_SYSTEM_NAME SDCC_PIC_16F877A)
# Finding resource settings
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
# Set default MCU family and model
if (NOT MICROCHIP_FAMILY)
set(MICROCHIP_FAMILY "pic16")
endif()
if (MICROCHIP_MODEL STREQUAL "pic16")
set(MICROCHIP_MODEL "16f877a")
endif()
# Need a better way to detect the supported models here
if (NOT MICROCHIP_FAMILY STREQUAL "pic16" AND NOT MICROCHIP_MODEL STREQUAL "16f877a")
message(FATAL_ERROR "Settings not supported. Please drop a request.")
endif()
if (NOT SDCC_ROOT)
message(FATA_ERROR "Need to provide the root (from toolchain.)")
endif()
# Cache those variables
set(SDCC_ROOT "${SDCC_ROOT}"
CACHE INTERNAL "Root directory of SDCC installation")
set(MICROCHIP_FAMILY "${MICROCHIP_FAMILY}"
CACHE INTERNAL "Family of the chip to compile for")
set(MICROCHIP_MODEL "${MICROCHIP_MODEL}"
CACHE INTERNAL "Model of the chip to compile for")
the Module/Platform/SDCC_PIC_16F877A.cmake file has the contents:
# Check if the shit exists
message("!!! The value of root is ${SDCC_ROOT}")
if (NOT SDCC_ROOT)
message(FATAL_ERROR
"SDCC_ROOT is not defined. Please set this variable e.g.\n"
"cmake -DSDCC_ROOT=\"C:/Program Files/sdcc\"")
endif()
# Finding the compilers
find_program(CMAKE_C_COMPILER
sdcc
PATHS ${SDCC_ROOT}
PATH_SUFFIXES "bin"
DOC "path to the SDCC C compiler.")
and my CMakeLists.txt is the following:
cmake_minimum_required(VERSION 3.10)
project(PicExample)
message("THE COMPILER IS ${CMAKE_C_COMPILER}")
add_executable(pic_example main.c)
what I invoke from my project/build directory and the error I get:
cmake -DCMAKE_MODULE_PATH:FILEPATH="/mnt/c/Users/mathe/Desktop/coding/sdcc-pic-template/Modules" -DCMAKE_TOOLCHAIN_FILE:FILEPATH="/mnt/c/Users/mathe/Desktop/coding/sdcc-pic-template/Modules/toolchain.cmake" -DSDCC_ROOT="testing/" ..
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
!!! The value of root is testing/
!!! The value of root is testing/
-- Check for working C compiler: /usr/bin/cc
FATA_ERRORNeed to provide the root (from toolchain.)
!!! The value of root is
CMake Error at /mnt/c/Users/mathe/Desktop/coding/sdcc-pic-template/Modules/Platform/SDCC_PIC_16F877A.cmake:4 (message):
SDCC_ROOT is not defined. Please set this variable e.g.
cmake -DSDCC_ROOT="C:/Program Files/sdcc"
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/CMakeSystemSpecificInformation.cmake:26 (include)
/mnt/c/Users/mathe/Desktop/coding/sdcc-pic-template/build/CMakeFiles/CMakeTmp/CMakeLists.txt:3 (project)
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:44 (try_compile):
Failed to configure test project build system.
Call Stack (most recent call first):
CMakeLists.txt:2 (project)
-- Configuring incomplete, errors occurred!
See also "/mnt/c/Users/mathe/Desktop/coding/sdcc-pic-template/build/CMakeFiles/CMakeOutput.log".
Why do the toolchain files get "executed" more than once by CMake and has no access to cache in the latest runs? I've been finding CMake documentation for cross-compilation very difficult, especially if you are working with a non-standard compiler.
I am aware that other people have had same issues before, but I am not simply asking for a simple hacky solution (setting environment variables). I actually want to know why this happens (which the previous answers don't tackle).
Tsyvarev answered the why the toolchain is used multiple times in CMake. TLDR; CMake needs it for multiple try_compile() calls it uses internally for error checking and other things.
This works just fine for me.
-DCMAKE_MODULE_PATH="${PATH_TO_MY_MODULES}" -DCMAKE_TOOLCHAIN_FILE="${PATH_TO_MY_TOOLCHAIN}" -DSDCC_SYSROOT="SOME_VALUE",
To fix your problem here is what you need to do.
Essentially you are passing an argument to your toolchain file. And this argument SDCC_SYSROOT essentially goes out of scope.
To fix this problem here is what you need to do.
# Use list(APPEND) rather than set() so that any variables added by CMake aren't lost!
#
# Here is the docs for this variable:
# https://cmake.org/cmake/help/latest/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES.html
list(APPEND CMAKE_TRY_COMPILE_PLATFORM_VARIABLES ${SDCC_SYSROOT})
If you want to see how many times your toolchain script gets executed try putting in a message() call in there for fun.
And if you are really interested look inside your build folder and see what it is CMake is doing.
If you are wondering how I know this information it's because I read the toolchain section in Craig Scott's CMake book "Professional CMake:
A Practical Guide"
Here is a link: https://crascit.com/professional-cmake/
For determine, whether some feature is supported by the compiler or by some library, CMake uses try_compile approach: during the configuration phase, it creates separate CMake project and immediately configures and builds it. Because it is a separate project, its configuration has the same steps as the main project and it loads the toolchain file too.
try_compile could be used by the (user) project for check features of the library or of the compiler. There are many CMake modules which use try_compile in their implementation. E.g. CheckSymbolExists.
try_compile is also used by CMake itself, in platform files, when it perform basics checks for the compiler. In your log you could find the line:
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:44 (try_compile)
Aside from try_compile, the new CMake project is created in ExternalProject_Add command. That creation is also accompanied by the reading of the toolchain file. (More correctly, the new project is created not when ExternalProject_Add invocation is processed but when corresponding project is configured. This configuration is performed on the build stage of the main project.)
I am doing my first steps in CMake and I have a Hello World example where I would like to use libgit2. My directory structure is the following:
- main.cpp
- CMakeLists.txt
- cmake/Modules/Findlibgit2.cmake
- libs/libgit2/include/git2.h
- libs/libgit2/debug/git/git2.lib
- libs/libgit2/debug/git/git2.dll
I would like to link it either statically, or dynamically, at least it works for the beginning. But when I execute CMake, I receive the error message below. Could anyone help me with this?
Not searching for unused variables given on the command line.
[cmake] CMake Error at C:/Program Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
[cmake] Could NOT find libgit2 (missing: GIT2_LIBRARY GIT2_INCLUDE_PATH)
[cmake] Call Stack (most recent call first):
[cmake] C:/Program Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE)
[cmake] cmake/Modules/Findlibgit2.cmake:15 (find_package_handle_standard_args)
[cmake] CMakeLists.txt:6 (find_package)
Findlibgit2.cmake
# Find git2 Library
#
# GIT2_INCLUDE_DIRS - where to find git2.h, etc.
# GIT2_LIBRARIES - List of libraries when using libgit2.
# GIT2_FOUND - True if libgit2 is found.
# GIT2_INCLUDE_PATH
find_path(GIT2_INCLUDE_PATH NAMES git2.h)
# GIT2_LIBRARY
find_library(GIT2_LIBRARY NAMES git2)
# handle the QUIETLY and REQUIRED arguments and set GIT2_FOUND to TRUE if
# all listed variables are TRUE
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(libgit2 REQUIRED_VARS GIT2_LIBRARY GIT2_INCLUDE_PATH)
if (GIT2_FOUND)
set(GIT2_INCLUDE_DIR ${GIT2_INCLUDE_PATH})
set(GIT2_INCLUDE_DIRS ${GIT2_INCLUDE_PATH})
set(GIT2_LIBRARIES ${GIT2_LIBRARY})
endif()
mark_as_advanced(
GIT2_INCLUDE_PATH
GIT2_LIBRARY
)
CMakeLists.txt
cmake_minimum_required(VERSION 2.8.9)
project (backend)
SET(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules/")
find_package(libgit2 REQUIRED)
include_directories(${LIBGIT2_INCLUDE_DIR})
link_directories("backend/libs/libgit2/debug")
add_executable(backend main.cpp)
It seems like libgit2 doesn't provide a CMake package configuration file, so it would be up to you to write a Find Module or find one on the internet. The Findlibgit2.cmake file you have is a good start.
I found another libgit2 Find Module online here: Findlibgit2.cmake. This one utilizes pkg-config, leveraging the .pc file provided by libgit2 itself, but, considering you're using Windows, would require you to install pkg-config manually. This may be more trouble than it's worth.
Regarding your error message:
Unless the libgit2 package is in the standard system path, CMake will not know where to look for it. So, you must explicitly tell CMake where to look. One simple way to do this is by modifying your Findlibgit2.cmake file, using HINTS for the find_* commands:
# GIT2_INCLUDE_PATH
find_path(GIT2_INCLUDE_PATH NAMES git2.h
HINTS ${GIT2_INCLUDEDIR}
)
# GIT2_LIBRARY
find_library(GIT2_LIBRARY NAMES git2
HINTS ${GIT2_LIBRARYDIR}
)
Now, we can populate these GIT2_INCLUDEDIR and GIT2_LIBRARYDIR variables to point to the installed libgit2 package. After doing so, find_package() should then succeed in finding the package components, and you can link to git2.lib using ${GIT2_LIBRARIES}.
CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.9)
project (backend)
SET(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules/")
# Set hints so CMake knows where libgit2 is located on your machine.
set(GIT2_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/libs/libgit2/include)
set(GIT2_LIBRARYDIR ${CMAKE_CURRENT_LIST_DIR}/libs/libgit2/debug/git)
find_package(libgit2 REQUIRED)
include_directories(${GIT2_INCLUDE_DIR})
# Don't need this line. Use of 'link_directories' is discouraged.
link_directories("backend/libs/libgit2/debug")
add_executable(backend main.cpp)
# Add this line to link against the libgit2 libraries.
target_link_libraries(backend PRIVATE ${GIT2_LIBRARIES})
A more portable way to set these HINTS variables is to instead set them when calling cmake on the command line:
cmake -DGIT2_INCLUDEDIR=C:/path/to/libgit2/include -DGIT2_LIBRARYDIR=D:/path/to/libgit2/lib ..
This way, if you have other developers working with the project, they can point to wherever they may have libgit2 installed on their machine, eliminating the need to modify the CMakeLists.txt file.
Hi im trying to get cmake to find dbus-1
I keep getting this error when i try to compile
-- Checking for module 'dbus-1'
-- No package 'dbus-1' found
Ive tried this command
pkg-config --cflags dbus-glib-1
I get the output
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
I edited the CMakeLists.txt and added
include_directories(/usr/include/dbus-1.0/)
What am i doing wrong??
The first thing to know about CMake in this situation is don't use the include_directories to include any system directories with a hard-coded path(which is what you are doing now). What you should do instead is use the CMake FindPkgConfig module which will call pkg-config and get those include directories for you.
To do this, something like the following should work.
include( FindPkgConfig )
pkg_check_modules( dbus REQUIRED dbus-1 )
# Add the include directories to our target executable/shared object.
# In this case, our target is called 'executable' and must have been
# created by a previous call to either 'add_executable' or 'add_library'
target_include_directories( executable PUBLIC ${dbus_INCLUDE_DIRECTORIES} )
Using
find_package(Protobuf REQUIRED
PATHS ${PROTOBUF_SEARCH_PATH}
)
if (NOT ${Protobuf_FOUND})
message( FATAL_ERROR "Could not find Protobuf!" )
endif()
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS Foo.proto)
I am getting an error message Unknown CMake command "protobuf_generate_cpp". If I check install folder of Protobuff, there is a CMake file <istall path>/cmake/protobuf-module.cmake which contains the function definition.
CMake version: 3.10.2
Protobuf version: 3.6.1
What is the problem here?
Looks like the cmake API has changed a bit. Try changing it to
protobuf_generate(
LANGUAGE cpp
TARGET <YOUR_TARGET_NAME>
PROTOS Foo.proto)
This will directly add the generated files to the target's source list.
Have a look in at the protobuf_generate function in protobuf-config.cmake for the new options.
The existing answers helped me but miss a lot of explanation of what is going on.
find_package can work in MODULE mode or CONFIG mode.
In MODULE mode it searches for Find\<package\>.cmake (typically owned by cmake).
In CONFIG mode it searches for \<package\>Config.cmake (provided by the package).
Both cmake and protocol buffers can provide an implementation for protobuf_generate_cpp():
>grep -ri 'function(PROTOBUF_GENERATE_CPP' /opt/cmake-3.18.1/
/opt/cmake-3.18.1/share/cmake-3.18/Modules/FindProtobuf.cmake:function(PROTOBUF_GENERATE_CPP SRCS HDRS)
>grep -ri 'function(PROTOBUF_GENERATE_CPP' /opt/protobuf-3.5.0/
/opt/protobuf-3.5.0/lib64/cmake/protobuf/protobuf-module.cmake:function(PROTOBUF_GENERATE_CPP SRCS HDRS)
Using the PATHS hint puts cmake into CONFIG mode so that it will use the protobuf provided implementation if it can find a Config.cmake module.
In this case protobuf_generate_cpp() comes from config.cmake which requires:
set(protobuf_MODULE_COMPATIBLE ON CACHE BOOL "")
Because as #HaxtraZ mentions the config module contains:
if(protobuf_MODULE_COMPATIBLE)
include("${CMAKE_CURRENT_LIST_DIR}/protobuf-module.cmake")
endif()
This is not required if using the FindProtobuf MODULE and is thus not documented there.
Though it is not really its fault cmake could warn about the possible conflict.
If have raised this here:
https://gitlab.kitware.com/cmake/cmake/-/issues/21228
I have also reported the confusion caused by the missing documentation to the protocol buffers project here:
https://github.com/protocolbuffers/protobuf/issues/7912
Note: The default on some Linux installations (at least CentOS7 and Debian9) is typically to have protocol buffers produced using configure/make rather than cmake which does not install the cmake config files at all. So find_package(protobuf 3.5.0 REQUIRED) will work but find_package(protobuf 3.5.0 REQUIRED PATH I/only/wanted/to/help) will fail.
You need protobuf_MODULE_COMPATIBLE.
I'm using CMake3.14. The last 3 lines of protobuf-config.cmake is:
if(protobuf_MODULE_COMPATIBLE)
include("${CMAKE_CURRENT_LIST_DIR}/protobuf-module.cmake")
endif()
and protobuf_generate_cpp() is defined in protobuf-module.cmake.
So, in order to protobuf_generate_cpp(), people have to turn protobuf_MODULE_COMPATIBLE on in their CMakeLists.txt:
set(protobuf_MODULE_COMPATIBLE ON CACHE BOOL "")
Remember clean your previously generate cmake cache files then call cmake again.
l am trying to build a java example for the td lib following the README(https://github.com/tdlib/td/tree/master/example/java)
I have got following mistackes. Please tell how can I fix it?
C:\Users\irina\td\jnibuild>cmake -DCMAKE_BUILD_TYPE=Debug -DTD_ENABLE_JNI=ON -DCMAKE_INSTALL_PREFIX:PATH=../example/java/td ..
-- Could NOT find ccache
-- Found OpenSSL: C:/OpenSSL-Win32/include optimized;C:/OpenSSL-Win32/lib/VC/ssleay32MD.lib;debug;C:/OpenSSL-Win32/lib/VC/ssleay32MDd.lib;optimized;C:/OpenSSL-Win32/lib/VC/libeay32MD.lib;debug;C:/OpenSSL-Win32/lib/VC/libeay32MDd.lib
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
CMake Warning at CMakeLists.txt:256 (message):
Not found zlib: skip TDLib, tdactor, tdnet, tddb
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
ZLIB_LIBRARY
linked by target "tdutils" in directory C:/Users/irina/td/tdutils
-- Configuring incomplete, errors occurred!
See also "C:/Users/irina/td/jnibuild/CMakeFiles/CMakeOutput.log".
See also "C:/Users/irina/td/jnibuild/CMakeFiles/CMakeError.log".
ZLIB for Windows is a part of the GnuWin32 project (I'm not sure whether it is allowed to give links on SO). As I see, the CMakeLists.txt uses find_package to lookup the ZLIB library:
if (NOT ZLIB_FOUND)
find_package(ZLIB)
endif()
if (NOT ZLIB_FOUND)
message(WARNING "Not found zlib: skip TDLib, tdactor, tdnet, tddb")
return()
endif()
How the find_package command works is well described in the official documentation:
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. It is responsible for finding the
package, checking the version, and producing any needed messages. Many find-
modules provide limited or no support for versioning; check the module
documentation. If no module is found and the MODULE option is not given the
command proceeds to Config mode.
I've had a look into FindZLIB.cmake on my Windows machine. The module uses the following path: ZLIB_ROOT and the following registry keys:
"[HKEY_LOCAL_MACHINE\SOFTWARE\GnuWin32\Zlib;InstallPath]"
"$ENV{PROGRAMFILES}/zlib
So, as I understand, if you install GnuWin32 using the installer, the HKLM key will be written down into the registry and CMake will be able to find the path to ZLIB. If you wish to use just the zip-archive, the ZLIB_ROOT parameter must be correctly specified when you run CMake:
cmake -DZLIB_ROOT=<PATH-to-your-unpacked-zlib> -D.....