I want to check whether my C++ project compiles on an older version of GCC. For this reason I have installed the older version and want CMake to use it to compile my project.
The CMake FAQ on changing the compiler tells me that this is the right way to do it:
CC=gcc-4.4 CXX=g++-4.4 cmake -G "Unix Makefiles" ..
So this is what I typed and CMake seems to run fine:
chris#chris-machine:~/projects/myProject/build$ CC=gcc-4.4 CXX=g++-4.4 cmake -G "Unix Makefiles" ..
-- Found PythonInterp: /usr/bin/python (found version "2.7.4")
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /home/chris/projects/myProject/build
However, looking at CMakeCache.txt now I find this:
//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
Obviously CMake did not use the compiler I specified. When I change this line to use g++-4.4 and run CMake again it will create an endless loop:
chris#chris-machine:~/projects/myProject/build$ CC=gcc-4.4 CXX=g++-4.4 cmake -G "Unix Makefiles" ..
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= /usr/bin/g++-4.4
-- Found PythonInterp: /usr/bin/python (found version "2.7.4")
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= /usr/bin/g++-4.4
-- Found PythonInterp: /usr/bin/python (found version "2.7.4")
// and so on...
Why does CMake not use the compiler I specify and how can I fix this?
From link you provide:
This method is not guaranteed to work for all generators
Use the second method:
cmake -G "Your Generator" -D CMAKE_C_COMPILER=gcc-4.4 -D CMAKE_CXX_COMPILER=g++-4.4 path/to/your/source
If it not help:
use absolute path
do not forget to clean all in build directory
I've come across this exact issue as well. Apparently this is a "won't fix" issue in CMake: https://cmake.org/Bug/view.php?id=14841
One work-around is to remove the CMakeCXXCompiler.cmake file inside the build directory's CMakeFiles directory every time you want to re-generate your build directory.
The path should be: build_directory/CMakeFiles/CMAKE_VERSION/CMakeCXXCompiler.cmake. On Linux, you can get your CMAKE_VERSION programmatically with cmake --version | cut -d ' ' -f 3.
A neat "fix" would be to simply add the removal of that file into your build script whenever you anticipate you will come across this.
Related
Similar questions already exist but I haven't found an answer that works.
I need to build a wxWidgets project in Windows using MinGW, I would like to use the cmake command from the command line (I installed mingw, cmake and bash using chocolatey)
I would like to avoid compiling wxWidgets so I am using the pre-built binaries MinGW-w64 10.2 (Headers + Dev x64 + Release x64), I unpack them to C:\wxWidgets-3.1.5
I've tried a number of combinations of arguments for cmake but haven't found one that works on the first run, I say first run because I've found one that works on the second:
cmake .. -G "MinGW Makefiles" \
-DwxWidgets_ROOT_DIR=/c/wxWidgets-3.1.5/ \
-DwxWidgets_LIB_DIR=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/
I am not a cmake expert but I imagine that by specifying these arguments in the first run they are cached and in the second run they are used, bypassing the search.
What I would like to know is what arguments I have to give to get them to be found correctly, _CONFIGURATION, _ROOT_DIR, _LIBRARIES, _INCLUDE_DIRS don't seem to have any effect.
↓ edit ↓
CMakelists.txt:
cmake_minimum_required(VERSION 3.18)
project(Test)
set(wxWidgets_USE_LIBS)
find_package(wxWidgets REQUIRED)
if(wxWidgets_FOUND)
include(${wxWidgets_USE_FILE})
add_executable(MyTest WIN32 main.cpp)
target_link_libraries(MyTest ${wxWidgets_LIBRARIES})
else(wxWidgets_FOUND)
message("wxWidgets not found!")
endif(wxWidgets_FOUND)
command line used:
cmake .. -G "MinGW Makefiles" -DwxWidgets_ROOT_DIR=/c/wxWidgets-3.1.5/ -DwxWidgets_LIB_DIR=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/ -DwxWidgets_wxrc_EXECUTABLE=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/wxrc.exe -DCMAKE_BUILD_TYPE=Release -DwxWidgets_LIBRARIES=/c/wxWidgets-3.1.5/lib/gcc1020_x64_dll/ -DwxWidgets_INCLUDE_DIRS=/c/wxWidgets-3.1.5/include/
first run:
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/ProgramData/chocolatey/bin/gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/ProgramData/chocolatey/bin/g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS core base)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Alex/Documents/Progetti/wx-test/build
wxWidgets not found!
second run:
-- Found wxWidgets: debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxmsw31ud_core.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxmsw31u_core.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31ud.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31u.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31ud_net.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxbase31u_net.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxpngd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxpng.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxtiffd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxtiff.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxjpegd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxjpeg.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxzlibd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxzlib.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxregexud.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxregexu.a;debug;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxexpatd.a;optimized;C:/wxWidgets-3.1.5/lib/gcc1020_x64_dll/libwxexpat.a;winmm;comctl32;uuid;oleacc;uxtheme;rpcrt4;shlwapi;version;wsock32 (found version "3.1.5") found components: core base net png tiff jpeg zlib regex expat
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Alex/Documents/Progetti/wx-test/build
if I use find_package(wxWidgets REQUIRED):
CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES
wxWidgets_INCLUDE_DIRS)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.21/Modules/FindwxWidgets.cmake:1025 (find_package_handle_standard_args)
CMakeLists.txt:24 (find_package)
Thanks to Process Monitor I noticed that FindwxWidgets.cmake looks for libraries in gcc_dll/ (not gcc2010_x64_dll/), once the directory was renamed cmake -G "MinGW Makefiles" -DwxWidgets_ROOT_DIR=/c/wxWidgets-3.1.5 was enough to find the directory on the first run.
I'm using cmake to compile a C++ project, and I want cmake to generate all the output files(metafiles like Makefile used to create binaries) in the build folder. I've checked all the answers in How do I make cmake output into a 'bin' dir?, none of them worked for me(suprisingly!). Files are generated in the root folder instead of in the build folder, what's wrong here? I guess I must have missed something.
Code Structure
➜ cmake-test tree .
.
├── CMakeLists.txt
└── hello.cpp
0 directories, 2 files
CMakeLists.txt
# Specify the minimum version for CMake
cmake_minimum_required(VERSION 3.11)
# Project's name
project(hello)
# Set the output folder where your program will be created
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/build)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/build)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
# The following folder will be included
include_directories("${PROJECT_SOURCE_DIR}")
add_executable(hello ${PROJECT_SOURCE_DIR}/hello.cpp)
Build Commands and Outputs
➜ cmake-test cmake .
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/searene/CLionProjects/cmake-test
➜ cmake-test ls
bin CMakeCache.txt CMakeFiles cmake_install.cmake CMakeLists.txt hello.cpp Makefile
cmake version
➜ cmake-test cmake --version
cmake version 3.11.4
CMake suite maintained and supported by Kitware (kitware.com/cmake).
OS
Linux
The usual way to do this, rather than changing variables to set the path, is simply to create the output directory, change to it, and run cmake from there. So instead of cmake . you usually have cmake .. or similar.
I understand the initial impulse to say "But I expect my build system to write output somewhere else." But CMake is not usually used in the way you were initially expecting, and other people who run your CMake build won't expect what you were expecting, so it's probably best to just use the built-in, default behavior, which is to put the output wherever cmake was run.
Put another way: You are fighting against the tool. Don't do that.
Disclaimer: I recommend going with #john-zwinck's answer.
By default, cmake uses the current working directory as build directory and whatever path you provide as source directory. So the normal way of achieving your goal is
create the build directory (mkdir build)
go there (cd build)
call cmake with the source dir as argument (cmake path/to/source)
BUT there is another way, as far as I know not documented in the cmake docs and only kept for compatibility reasons or internal usage, that some people are using. The -B and -H flags
cmake -Hpath/to/source -Bpath/to/build
or even from the source dir
cmake . -Bbuild
Important: no space after -B.
CMake 3.19.1 (not sure how about older ones) has following option (from docs):
cmake [<options>] -S <path-to-source> -B <path-to-build>
Uses as the build tree and as the
source tree. The specified paths may be absolute or relative to the
current working directory. The source tree must contain a
CMakeLists.txt file. The build tree will be created automatically if
it does not already exist. For example:
cmake -S src -B build
I have a problem with this CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6)
SET(CMAKE_C_COMPILER C:/MinGW/bin/gcc)
SET(CMAKE_CXX_COMPILER C:/MinGW/bin/g++)
project(cmake_test)
add_executable(a.exe test.cpp)
Calling cmake with: cmake -G "MinGW Makefiles" , it fails with the following output:
c:\Users\pietro.mele\projects\tests\buildSystem_test\cmake_test>cmake -G "MinGW Makefiles" .
-- The C compiler identification is GNU 4.6.1
-- The CXX compiler identification is GNU 4.6.1
-- Check for working C compiler: C:/MinGW/bin/gcc
CMake Error: your C compiler: "C:/MinGW/bin/gcc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name.
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working C compiler: C:/MinGW/bin/gcc -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "C:/MinGW/bin/gcc" is not able to compile a simple test
program.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:10 (project)
CMake Error: your C compiler: "C:/MinGW/bin/gcc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name.
CMake Error: your CXX compiler: "C:/MinGW/bin/g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
-- Configuring incomplete, errors occurred!
However the gcc compiler is in C:/MinGW/bin/ and it works.
Any idea?
Platform:
Windows 7
MinGW/GCC 4.6
Never try to set the compiler in the CMakeLists.txt file.
See the CMake FAQ about how to use a different compiler:
https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler
(Note that you are attempting method #3 and the FAQ says "(avoid)"...)
We recommend avoiding the "in the CMakeLists" technique because there are problems with it when a different compiler was used for a first configure, and then the CMakeLists file changes to try setting a different compiler... And because the intent of a CMakeLists file should be to work with multiple compilers, according to the preference of the developer running CMake.
The best method is to set the environment variables CC and CXX before calling CMake for the very first time in a build tree.
After CMake detects what compilers to use, it saves them in the CMakeCache.txt file so that it can still generate proper build systems even if those variables disappear from the environment...
If you ever need to change compilers, you need to start with a fresh build tree.
I had similar problem as Pietro,
I am on Window 10 and using "Git Bash".
I tried to execute >>cmake -G "MinGW Makefiles", but I got the same error as Pietro.
Then, I tried >>cmake -G "MSYS Makefiles", but realized that I need to set my environment correctly.
Make sure set a path to C:\MinGW\msys\1.0\bin and check if you have gcc.exe there. If gcc.exe is not there then you have to run C:/MinGW/bin/mingw-get.exe and install gcc from MSYS.
After that it works fine for me
Using with FILEPATH option might work:
set(CMAKE_CXX_COMPILER:FILEPATH C:/MinGW/bin/gcc.exe)
I had the same issue. And in my case the fix was pretty simple. The trick is to simply add the ".exe" to your compilers path. So, instead of :
SET(CMAKE_C_COMPILER C:/MinGW/bin/gcc)
It should be
SET(CMAKE_C_COMPILER C:/MinGW/bin/gcc.exe)
The same applies for g++.
Since yesterday none of my packages containing tests build. Catkin complains it cannot find gtest when using catkin_add_gtests(), since GTEST_FOUND is FALSE. You can see this in the error msg below, with the custom output I added to my CMakeLists. Up to yesterday, GTEST_FOUND was TRUE when catkin_add_gtests() was called.
This is the error I always get. In this case I'm trying to build a mockup package on a clean catkin workspace:
Errors << silly_pkg:cmake /home/paco/catkin_ws2/logs/silly_pkg/build.cmake.002.log
Not searching for unused variables given on the command line.
Re-run cmake no build system arguments
-- Using CATKIN_DEVEL_PREFIX: /home/paco/catkin_ws2/devel/.private/silly_pkg
-- Using CMAKE_PREFIX_PATH: /home/paco/catkin_ws2/devel;/opt/ros/kinetic
-- This workspace overlays: /home/paco/catkin_ws2/devel;/opt/ros/kinetic
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/paco/catkin_ws2/build/silly_pkg/test_results
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.11
-- GTEST_FOUND: FALSE
CMake Warning at /opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake:149 (message):
skipping gtest 'test_silly_pkg' in project 'silly_pkg' because gtest was
not found
Call Stack (most recent call first):
/opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake:79 (_catkin_add_executable_with_google_test)
/opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake:28 (_catkin_add_google_test)
CMakeLists.txt:28 (catkin_add_gtest)
CMake Error at /home/paco/catkin_ws2/src/silly_pkg/CMakeLists.txt:33 (target_link_libraries):
Cannot specify link libraries for target "test_silly_pkg" which is not
built by this project.
-- Configuring incomplete, errors occurred!
See also "/home/paco/catkin_ws2/build/silly_pkg/CMakeFiles/CMakeOutput.log".
See also "/home/paco/catkin_ws2/build/silly_pkg/CMakeFiles/CMakeError.log".
cd /home/paco/catkin_ws2/build/silly_pkg; catkin build --get-env silly_pkg | catkin env -si /usr/bin/cmake /home/paco/catkin_ws2/src/silly_pkg --no-warn-unused-cli -DCATKIN_DEVEL_PREFIX=/home/paco/catkin_ws2/devel/.private/silly_pkg -DCMAKE_INSTALL_PREFIX=/home/paco/catkin_ws2/install; cd -
I am using catkin 0.7.11, libgtest-dev 1.7.0 and cmake 3.5.1. I use ROS Kinetic with Ubuntu 16.04. The only thing I did yesterday was reinstalling ROS Kinetic, but the package versions are exactly the same. Did anybody have this problem? Do you have any ideas on what could be happening?
EDIT 3/09/18:
By comparing with a functional catkin+gtest workspace in a different computer, I found out that the main difference is in the results of /opt/ros/kinetic/share/catkin/cmake/test/gtest.cmake. In the functional workspace, line 292 evaluates to TRUE (gtest/gmock is not a target) while in my workspace it evaluates to FALSE. This is because in my workspace running find_package(GMock QUIET) (line 287) sets gmock and gtest as imported targets, which does not happen in the other computer. Why is this different?
Thanks TikO for your help!
Since you wrote that cmake does not find the libraries and that you have reinstalled Kinetic, I assume that you have a freshly installed machine or wiped out gtest libraries by accident.
If you install libgtest-dev, you only get the sources which you need to build and install like this:
sudo apt-get install libgtest-dev
mkdir /tmp/gtest_build && cd /tmp/gtest_build
cmake /usr/src/gtest
make
#copy or symlink libgtest.a and ligtest_main.a to /usr/lib folder
sudo cp *.a /usr/lib
After this routine, you should be able to build again without cmake complaining.
Optional
If you have limited rights on your machine and you are not allowed to install the libraries in that way, just copy them into some home folder like
mkdir ~/lib && cp *.a ~/lib
But be aware of the fact, that you have to call catkin in the following way:
LIBRARY_PATH=~/lib GTEST_ROOT=~/lib catkin_make
LIBRARY_PATH tells the linker where to find the libraries, while GTEST_ROOT gives cmake the location hints for it's checks.
Reference: https://github.com/tik0/gtest_ros_example
SOLUTION FOUND
gmock and gtest were being set to imported target because the suggested manual compilation of libgtest had created a FindGMock.cmake file inside /usr/share/cmake-3.5/Modules. This file was being called by the find(GMock QUIET)
in catkin_add_gtests(), therefore setting the imported target. Just deleting FindGMock.cmake solved the issue.
I am trying to install fbtorch on linux. However, when I try to run luarocks install fbtorch I get the following error.
cmake -E make_directory build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="/home/user/torch/install/bin/.." -DCMAKE_INSTALL_PREFIX="/home/user/torch/install/lib/luarocks/rocks/fbtorch/scm-1"
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Torch7 in /home/user/torch/install
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
REQUIRED_ARGS (missing: FOLLY_INCLUDE_DIR FOLLY_LIBRARIES)
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
cmake/FindFolly.cmake:23 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:12 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
See also "/tmp/luarocks_fbtorch-scm-1-4920/fbtorch/build/CMakeFiles/CMakeOutput.log".
Now, to fix the REQUIRED_ARGS (missing: FOLLY_INCLUDE_DIR FOLLY_LIBRARIES) I changed the cmake command to:
cmake -E make_directory build && cd build && cmake .. -DFOLLY_LIBRARIES="/home/user/local/lib" -DFOLLY_INCLUDE_DIR="/home/user/local/include" -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="$(LUA_BINDIR)/.." -DCMAKE_INSTALL_PREFIX="$(PREFIX)"
Kindly note that I have compiles and installed folly at /home/user/local/ in appropriate directories
This fixed the FOLLY_INCLUDE_DIR error but its still showing error for FOLLY_LIBRARIES like so:
CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
REQUIRED_ARGS (missing: FOLLY_LIBRARIES)
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
cmake/FindFolly.cmake:23 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:12 (FIND_PACKAGE)
What am I missing here? Why did the cmake recognize the cache entry for FOLLY_INCLUDE_DIR but not for FOLLY_LIBRARIES?
Variables listed in "missed" list in find_package() call are not required to be CACHE ones. So, setting cache variable with the same name may do not resolve the problem.
If searched package is actually installed into non-standard location, instead of blindly setting "missing" variables it is better to hint the "Find" script about that location.
Many "Find" scripts describe possible ways of parametrization at the beginning of their code. Aside from this, there are common ways for hinting "Find" scripts about actual location of the package; these ways works for most of scripts. E.g. you may add install location of the package into CMAKE_PREFIX_PATH variable (See that question).
If you look at FindFolly.cmake you can see the line -
SET(FOLLY_LIBRARIES ${FOLLY_LIBRARY})
This means that FOLLY_LIBRARIES is being set but it needs FOLLY_LIBRARY.
So in your command line change -DFOLLY_LIBRARIES to -DFOLLY_LIBRARY