CMake is able to cross compile on 3rd invocation - cmake

I've to cross compile a 3rd party library which uses CMake.
In order to build something, I need to pass "-B path" flag to compiler.
foo.c :
void main(){}
Build command :
cross-gcc -B /path/to/somewhere -o foo.o foo.c
Without "-B path" option, the compiler simply does not work.
Hence I use the following lines in my cmake toolchain file :
SET(CMAKE_C_FLAGS "-B /path/to/somewhere")
SET(CMAKE_CXX_FLAGS "-B /path/to/somewhere")
But during the validation of compiler, CMake does not seem use the flags I set :
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /cross-path/cross-gcc
-- Check for working C compiler: /cross-path/cross-gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "cross-path/cross-gcc" is not able
to compile a simple test program.
....
....
/cross-path/cross-gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c CMakeFiles/CMakeTmp/testCCompiler.c
When I invoke CMake second time, cross-gcc passes the simple compilation test but this time cross-g++ fails :
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /cross-path/cross-gcc
-- Check for working C compiler: /cross-path/cross-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /cross-path/cross-g++
-- Check for working CXX compiler: /cross-path/cross-g++ -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "/cross-path/cross-g++" is not
able to compile a simple test program.
....
....
/cross-path/cross-g++ -o CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c CMakeFiles/CMakeTmp/testCXXCompiler.cxx
And if I invoke CMake 3rd time, everything works fine with only a warning :
....
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_TOOLCHAIN_FILE
I'm using CMake 2.8.7 and aware that it is quite outdated but upgrade is not an option if this is the case.
Edit :
Toolchain file :
# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_FLAGS "-B /path/to/somewhere")
SET(CMAKE_CXX_FLAGS "-B /path/to/somewhere")
# specify the cross compiler
SET(CMAKE_C_COMPILER /cross-path/cross-gcc)
SET(CMAKE_CXX_COMPILER /cross-path/cross-g++)

It looks that the problem of picking up the flags is very similar to one already discussed in SO in the past:
CMake cross-compiling: C flags from toolchain file ignored
Try the proposed solution, i.e. replace:
SET(CMAKE_C_FLAGS "-B /path/to/somewhere")
SET(CMAKE_CXX_FLAGS "-B /path/to/somewhere")
by
SET(CMAKE_C_FLAGS "-B /path/to/somewhere" CACHE STRING "" FORCE)
SET(CMAKE_CXX_FLAGS "-B /path/to/somewhere" CACHE STRING "" FORCE)
Try also to check if replacing your toolchain file with a new one that uses INCLUDE(CMakeForceCompiler) as mentioned in
http://www.vtk.org/Wiki/CMake_Cross_Compiling and
How can I make Cmake use specific compiler and flags when final compilation stage instead of detection? and
Cmake cross compile flags
INCLUDE(CMakeForceCompiler)
# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_FLAGS "-B /path/to/somewhere")
SET(CMAKE_CXX_FLAGS "-B /path/to/somewhere")
# specify the cross compiler
CMAKE_FORCE_C_COMPILER(/cross-path/cross-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(/cross-path/cross-g++ GNU)
...
has the same effect as the first hack. The second option seems a cleaner solution.

Related

Setting RPATH of Static Library in Executable

I have the following setup for my CMake project:
add_executable(exeA ${SOURCES})
target_link_libraries(exeA PRIVATE libB)
libB is a static library built separately in a different project and depends on shared libraries libC OR libD which provide equivalent API's but implemented differently and have different performance profiles.
In exeA's build I want to be able to link against either of libC or libD depending on a condition.
From reading RPATH handling, it seems I could use RPATH related CMake properties, however its unclear if I can use these properties to set the RPATH of an existing static library
Unfortunately there is no easy and fast way to change the RPATH of an
existing executable or shared library.
Is something like this possible to do in CMake?
Appreciate any recommendations to handle this use case.
Create a STATIC IMPORTED library for libB and SHARED IMPORTED libraries for libC and libD. Put the relevant one in the INTERFACE_LINK_LIBRARIES property of libB. CMake will set the RPATH correctly when exeA is built.
cmake_minimum_required(VERSION 3.23)
project(test)
# --------------------------------------------------
# The following code should probably be factored out
# into a proper Find module.
find_library(LIBB_LIBRARY NAMES B REQUIRED)
find_library(LIBC_LIBRARY NAMES C REQUIRED)
find_library(LIBD_LIBRARY NAMES D REQUIRED)
add_library(third-party::libC SHARED IMPORTED)
set_target_properties(
third-party::libC
PROPERTIES
IMPORTED_LOCATION "${LIBC_LIBRARY}"
)
add_library(third-party::libD SHARED IMPORTED)
set_target_properties(
third-party::libD
PROPERTIES
IMPORTED_LOCATION "${LIBD_LIBRARY}"
)
add_library(third-party::libB STATIC IMPORTED)
set_target_properties(
third-party::libB
PROPERTIES
IMPORTED_LOCATION "${LIBB_LIBRARY}"
)
option(LIBB_USES_LIBC "dummy option for demo" ON)
if (LIBB_USES_LIBC)
target_link_libraries(third-party::libB INTERFACE third-party::libC)
else ()
target_link_libraries(third-party::libB INTERFACE third-party::libD)
endif ()
# --------------------------------------------------
# --------------------------------------------------
# Project code
add_executable(exeA main.cpp)
target_link_libraries(exeA PRIVATE third-party::libB)
You can test this out with dummy files like so:
$ ls
CMakeLists.txt
$ mkdir -p prefix{1,2}/lib
$ touch prefix1/lib/lib{C,D}.so prefix2/lib/libB.a main.cpp
$ cmake -G Ninja -S . -B build "-DCMAKE_PREFIX_PATH=$PWD/prefix1;$PWD/prefix2"
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - 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: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/build
$ cmake --build build -- -nv # dry run (n), verbose (v)
[1/2] /usr/bin/c++ -MD -MT CMakeFiles/exeA.dir/main.cpp.o -MF CMakeFiles/exeA.dir/main.cpp.o.d -o CMakeFiles/exeA.dir/main.cpp.o -c /home/alex/test/main.cpp
[2/2] : && /usr/bin/c++ CMakeFiles/exeA.dir/main.cpp.o -o exeA -Wl,-rpath,/home/alex/test/prefix1/lib ../prefix2/lib/libB.a ../prefix1/lib/libC.so && :
As you can see, the RPATH is set correctly to the directory containing libC.so.

Define compiler and linker in CMAKE

I would like to use CMAKE to compile a special piece of code in C99 with language extensions. Therefore I have to use a "custom" compiler and linker /your/path/to/compiler and /your/path/to/linker. How can I define the compiler and the linker command used by CMAKE?
EDIT:
I tried to define the compiler and linker as suggested by Equod:
set(CMAKE_C_COMPILER /your/path/to/compiler)
set(CMAKE_CUSTOM_LINKER /your/path/to/linker)
set(CMAKE_C_LINK_EXECUTABLE
"<CMAKE_CUSTOM_LINKER> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
But CMAKE is still not taking it:
-- Building for: Visual Studio 15 2017
-- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.18363.
-- The C compiler identification is MSVC 19.16.27040.0
-- The CXX compiler identification is MSVC 19.16.27040.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Programms/VisualStudio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.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:/Programms/VisualStudio/2017/Professional/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x86/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/your/path/to/source/build
What I forgot to mention before, I am working on a Windows machine and the executable of th compiler and linker is in the PATH.
EDIT:
Here is my CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(MyProject
VERSION 1.0
DESCRIPTION "This is MyProject"
LANGUAGES C
)
set(CMAKE_C_COMPILER my_compiler)
set(CMAKE_C_LINK_EXECUTABLE my_linker)
configure_file(include/myproject_config.h.in include/myproject_config.h)
set(HEADER_FILES include/main.h include/somefunc.h)
set(SOURCE_FILES src/main.c src/somefunc.c)
add_executable(MyProject ${HEADER_FILES} ${SOURCE_FILES})
target_include_directories(MyProject PUBLIC "${PROJECT_BINARY_DIR}" )
target_include_directories(MyProject PUBLIC "../include" )
P.S.: my_compiler and my_linker are in PATH of cmd and PowerShell.
EDIT:
I installed MinGW now. I have make in my PATH as well. I updated the CMakeLists.txt file above. The make command tries to compile the code now with:
my_compiler #CMakeFiles/MyProject.dir/includes_C.rsp -o CMakeFiles\MyProject.dir\src\main.c.obj -c "C:\mypath\main.c"
But this is not working because I need a command like:
my_compiler -I="../include" "C:\mypath\main.c"
What CMake commands do I need to configure such a behavior?
CMake as default C compiler uses CC environment variables. You can also specify a different compiler and linker setting CMake variables:
Compiler:
set(CMAKE_C_COMPILER /your/path/to/compiler)
Linker:
set(CMAKE_CUSTOM_LINKER /your/path/to/linker)
set(CMAKE_C_LINK_EXECUTABLE
"<CMAKE_CUSTOM_LINKER> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
To better understand why linker settings are done in two steps I'd suggest taking a look at how those variables are managed internally by CMake:
CMake on github

Specify CMake generator unless explicitly passed as command argument by user

In all of the following, I'm using Windows, so WIN32 is always defined in CMake.
I have a CMakeLists.txt file which does its job fine, and I'm using a Preload.CMake file to specify a bunch of stuff, including a certain generator depending on circumstances:
if( WIN32 )
message( "Current generator: ${CMAKE_GENERATOR}" ) # For debugging purposes
if( NOT COMMAND cl OR NOT COMMAND nmake )
set( CMAKE_CXX_COMPILER "g++" )
set( CMAKE_GENERATOR "MinGW Makefiles" CACHE STRING "" FORCE )
set( CMAKE_MAKE_PROGRAM "make" )
message( "MSVC compiler could not be found, attempting with g++ and MinGW makefiles." )
endif( )
endif( )
This allows a Windows user with no Visual Studio to run cmake .. instead of a whole cmake .. -G "MinGW Makefiles".
It works pretty well, here is the output when cmake .. is run from an empty directory (no cache, no nothing):
Current generator:
MSVC compiler could not be found, attempting with g++ and MinGW makefiles.
Windows detected, forcing static libs.
-- The CXX compiler identification is GNU 8.2.0
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe
-- Check for working CXX compiler: C:/MinGW/bin/g++.exe -- 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: C:/Users/SAYENS/Desktop/picross/build
The problem with this is when I want to specify a generator through the command line. Here is what happens when I run cmake .. -G "MSYS Makefiles" from a MSYS terminal (empty directory, no cache):
Current generator:
MSVC compiler could not be found, attempting with g++ and MinGW makefiles.
CMake Error: Error: generator : MSYS Makefiles
Does not match the generator used previously: MinGW Makefiles
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
(There is no such file as CMakeCache.txt or a CMakeFiles directory, but explicitly specifying a generator in the command line, that is different from the one specified in Preload.CMake, seems to be enough of a source of confusion to print out this message.)
I thought I'd be able to work around the issue by "catching" the value of the -G argument with CMAKE_GENERATOR, but it turns out I can't, as per the first output line Current generator:.
How can I work this out? I tried looking for a way to parse command line arguments, but found none that doesn't involve using a wrapper script, which I'd like to avoid resorting to.
Set the generator name in the environment variable CMAKE_GENERATOR. The documentation says:
Specifies the CMake default generator to use when no generator is
supplied with -G. If the provided value doesn’t name a generator known
by CMake, the internal default is used. Either way the resulting
generator selection is stored in the CMAKE_GENERATOR variable.
Some generators may be additionally configured using the environment
variables:
CMAKE_GENERATOR_PLATFORM
CMAKE_GENERATOR_TOOLSET
CMAKE_GENERATOR_INSTANCE

How to auto generate pkgconfig files from cmake targets

I would like to generate pkgconfig files in cmake from the targets. I started by writing something like this:
function(auto_pkgconfig TARGET)
get_target_property(INCLUDE_DIRS ${TARGET} INTERFACE_INCLUDE_DIRECTORIES)
string(REPLACE "$<BUILD_INTERFACE:" "$<0:" INCLUDE_DIRS "${INCLUDE_DIRS}")
string(REPLACE "$<INSTALL_INTERFACE:" "$<1:" INCLUDE_DIRS "${INCLUDE_DIRS}")
string(REPLACE "$<INSTALL_PREFIX>" "${CMAKE_INSTALL_PREFIX}" INCLUDE_DIRS "${INCLUDE_DIRS}")
file(GENERATE OUTPUT ${TARGET}.pc CONTENT "
Name: ${TARGET}
Cflags: -I$<JOIN:${INCLUDE_DIRS}, -I>
Libs: -L${CMAKE_INSTALL_PREFIX}/lib -l${TARGET}
")
install(FILES ${TARGET}.pc DESTINATION lib/pkgconfig)
endfunction()
This is a simplified version but it basically reads the INTERFACE_INCLUDE_DIRECTORIES properties and processes the INSTALL_INTERFACE of the generator expressions.
This works well as long as the include directories are set before calling auto_pkgconfig, like this:
add_library(foo foo.cpp)
target_include_directories(foo PUBLIC
$<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include>
${OTHER_INCLUDE_DIRS}
)
auto_pkgconfig(foo)
However, sometimes properties are set after the call to auto_pkgconfig, like this:
add_library(foo foo.cpp)
auto_pkgconfig(foo)
target_include_directories(foo PUBLIC
$<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include>
${OTHER_INCLUDE_DIRS}
)
However, this won't properly read the include directories anymore. I would like auto_pkgconfig to run after all the target properties are set. I could use generator expressions for this, by changing auto_pkgconfig to this:
function(auto_pkgconfig TARGET)
file(GENERATE OUTPUT ${TARGET}.pc CONTENT "
Name: ${TARGET}
Cflags: -I$<JOIN:$<TARGET_PROPERTY:${TARGET},INTERFACE_INCLUDE_DIRECTORIES>, -I>
Libs: -L$<TARGET_FILE_DIR:${TARGET}> -l${TARGET}
")
install(FILES ${TARGET}.pc DESTINATION lib/pkgconfig)
endfunction()
However, this will read the BUILD_INTERFACE instead of the INSTALL_INTERFACE. So is there another way to read target properties after they have been set?
According to the CMake documentation, the contents of INSTALL_INTERFACE are only available when calling install(EXPORT). Unless they extend CMake, it will be best to do something else to generate your PkgConfig files. Ideally you would have enough control over your install layout to make this easy.
However, this doesn't mean you can't do what you ask; it's just "Tony the Pony" levels of evil. I actually hesitated to post this. Please don't take this as a recommendation.
The idea is to use install(EXPORT) to have CMake generate the appropriate scripts. Then generate a dummy CMake project that uses the file(GENERATE OUTPUT ...) code you gave above; the dummy project will see the exported, ie. INSTALL_INTERFACE properties.
I initially tried to use install(CODE [[ ... ]]) to do this, but it also sees the $<BUILD_INTERFACE:...> view. I've asked about this on the CMake Discourse.
cmake_minimum_required(VERSION 3.16)
project(example)
# Dummy library for demo
add_library(example SHARED example.cpp)
target_compile_definitions(example
PUBLIC $<BUILD_INTERFACE:BUILD>
$<INSTALL_INTERFACE:INSTALL>)
target_include_directories(example
PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:$<INSTALL_PREFIX>/include>)
# Here be dragons...
function(auto_pc TARGET)
file(CONFIGURE OUTPUT "pc.${TARGET}/CMakeLists.txt"
CONTENT [[
cmake_minimum_required(VERSION 3.16)
project(pc_#TARGET#)
find_package(pc_#TARGET# REQUIRED CONFIG)
file(GENERATE OUTPUT #TARGET#.pc
CONTENT [=[
Name: #TARGET#
Cflags: -I$<JOIN:$<TARGET_PROPERTY:INTERFACE_INCLUDE_DIRECTORIES>, -I> -D$<JOIN:$<TARGET_PROPERTY:INTERFACE_COMPILE_DEFINITIONS>, -D>
Libs: -L$<TARGET_FILE_DIR:#TARGET#> -l#TARGET#
]=] TARGET "#TARGET#")
]] #ONLY NEWLINE_STYLE LF)
install(TARGETS ${TARGET} EXPORT pc_${TARGET})
install(EXPORT pc_${TARGET} DESTINATION "_auto_pc" FILE pc_${TARGET}-config.cmake)
file(CONFIGURE OUTPUT "pc.${TARGET}/post-install.cmake"
CONTENT [[
file(REAL_PATH "${CMAKE_INSTALL_PREFIX}" prefix)
set(proj "#CMAKE_CURRENT_BINARY_DIR#/pc.#TARGET#")
execute_process(COMMAND "#CMAKE_COMMAND#" "-Dpc_#TARGET#_DIR=${prefix}/_auto_pc" -S "${proj}" -B "${proj}/build")
file(COPY "${proj}/build/#TARGET#.pc" DESTINATION "${prefix}")
]] #ONLY NEWLINE_STYLE LF)
install(SCRIPT "${CMAKE_CURRENT_BINARY_DIR}/pc.${TARGET}/post-install.cmake")
endfunction()
auto_pc(example)
# Clean up install path
install(CODE [[ file(REMOVE_RECURSE "${CMAKE_INSTALL_PREFIX}/_auto_pc") ]])
This results in the following:
alex#Alex-Desktop:~/test$ cmake -S . -B build
...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/build
alex#Alex-Desktop:~/test$ cmake --build build/
...
alex#Alex-Desktop:~/test$ cmake --install build --prefix install
-- Install configuration: ""
-- Installing: /home/alex/test/install/lib/libexample.so
-- Installing: /home/alex/test/install/_auto_pc/pc_example-config.cmake
-- Installing: /home/alex/test/install/_auto_pc/pc_example-config-noconfig.cmake
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - 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: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/test/build/pc.example/build
alex#Alex-Desktop:~/test$ ls install/
example.pc lib
alex#Alex-Desktop:~/test$ cat install/example.pc
Name: example
Cflags: -I/home/alex/test/install/include -DINSTALL
Libs: -L/home/alex/test/install/lib -lexample
This should make you sad. It makes me sad.
edit: off topic, since here, the pc files are generated manually
pkgconfig template files
motivation:
CMakeLists.txt should be the single source of truth (name, version)
pkgconfig files are about 10 times smaller than cmake files (cmake to pkgconfig is a lossy transformation)
template file: my_package.pc.in
prefix="#CMAKE_INSTALL_PREFIX#"
exec_prefix="${prefix}"
libdir="${prefix}/lib"
includedir="${prefix}/include"
Name: #PROJECT_NAME#
Description: #CMAKE_PROJECT_DESCRIPTION#
Version: #PROJECT_VERSION#
Cflags: -I${includedir}
Libs: -L${libdir} -l#target1#
CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(my_library VERSION 1.1.2 LANGUAGES C
DESCRIPTION "example library")
add_library(my_library src/my_library.c)
# generate pc file for pkg-config
set(target1 my_library)
configure_file(my_package.pc.in
lib/pkgconfig/my_package.pc #ONLY)
based on: CMake generate pkg-config .pc
related: exporting targets to cmake files

Changing compiler with cmake creates infinite loop

I try to change the compiler with cmake :
SET(CMAKE_C_COMPILER "/opt/rh/devtoolset-2/root/usr/bin/gcc")
SET(CMAKE_CXX_COMPILER "/opt/rh/devtoolset-2/root/usr/bin/g++")
I do that in the begining of my project just before calling the "PROJECT" command.
But I get an infinite loop when I call cmake, I have the following output:
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /opt/rh/devtoolset-2/root/usr/bin/gcc
-- Check for working C compiler: /opt/rh/devtoolset-2/root/usr/bin/gcc -- 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: /opt/rh/devtoolset-2/root/usr/bin/g++
-- Check for working CXX compiler: /opt/rh/devtoolset-2/root/usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Doxygen: /usr/bin/doxygen (found version "1.6.1")
-- Looking for C++ include tut.h
-- Looking for C++ include tut.h - found
-- [STATUS] Found tut.h
-- 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/c++
CMAKE_CXX_COMPILER= /usr/bin/c++
So I have this message again and again in an infinite loop, even if I delete the cache before calling cmake...
EDIT : Solution is quite simple : You need to use cmake version 2.8.9 and the problem doesnt appear.
The reason may be that other cmake module changes the variable you set. So find the cmake code and put it before your command (SET(CMAKE_CXX_COMPILER "/opt/rh/devtoolset-2/root/usr/bin/g++")), it should be solved.
I come across the problem with pybind11 submodule as following
SET(CMAKE_C_COMPILER /usr/bin/gcc)
SET(CMAKE_CXX_COMPILER /usr/bin/g++)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -march=native ")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -O3 -march=native")
add_subdirectory(pybind11)
The solution is changing it as:
add_subdirectory(pybind11)
SET(CMAKE_C_COMPILER /usr/bin/gcc)
SET(CMAKE_CXX_COMPILER /usr/bin/g++)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -march=native ")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -O3 -march=native")
Since this was the first result on Google for me, I figured I'd offer an alternate solution to Quentin's.
If you call your cmake command with -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake, you can then put your CMAKE_C_COMPILER and CMAKE_CXX_COMPILER overrides in a new toolchain.cmake file and cmake will properly load the overrides without an infinite loop.
This solutions offers a fix for those who cannot easily upgrade their cmake (such as if you are a non-root and non-sudo user), those who simply want to avoid the effort involved in upgrading packages or managing additional packages, or those who do not want to bother their sysadmin. Additionally, the toolchain.cmake file can still execute logic to find the appropriate or latest devtoolset should you want it to dynamically choose it.
This solution will not work for those who will not or cannot add the -DCMAKE_TOOLCHAIN_FILE argument to the cmake call.
Solution is quite simple : You need to use cmake version 2.8.9 and the problem doesnt appear.
on cmake3.15 I found out that once you remove the CMakeCache file and redo cmake it is all good