cmake generated header causes double build - c++

A very simple scenario - I need to generate header, include it and if generated header is updated while cmake build, all dependent cpp units also must be rebuilt.
A simplified example:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/test.h
COMMAND ...
DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/test.in"
add_custom_target(test_target DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/test.h)
add_executable(test_exe
${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
)
add_dependencies(test_exe test_target)
main.cpp is just:
#include "test.h"
int main()
{
return 0;
}
When I do a full rebuild, everything goes fine. But when I change test.in, run just cmake.exe --build . --target all only test.h is regenerated, but main.cpp is not recompiled. But when I run cmake.exe --build . --target all again(second time), main.cpp is recompiled and test_exe is relinked.
What do I wrong?
P.S. If I explicitly use OBJECT_DEPENDS, there is no issue, rebuild works fine, but the docs say it's not required anymore - https://cmake.org/cmake/help/v3.20/prop_sf/OBJECT_DEPENDS.html
Update:
I use Windows 10, CMake 3.19.2 and Ninja 1.10.2
Solution:
Use build directory inside your project dir, then there is no the problem. But if the build directory is outside of our project directory, then there is the problem.

Posting as an answer to be able to show full example
CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(example)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/test.h
COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_CURRENT_SOURCE_DIR}/test.in" ${CMAKE_CURRENT_SOURCE_DIR}/test.h
DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/test.in")
add_custom_target(test_target DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/test.h)
add_executable(test_exe
${CMAKE_CURRENT_SOURCE_DIR}/main.cpp
)
add_dependencies(test_exe test_target)
main.cpp
#include "stdio.h"
#include "test.h"
int main()
{
printf("The value is %d\n", FOO);
return 0;
}
test.in
#define FOO 4
This works on windows with CMake 3.19.2 and Ninja 1.10.2, one can change the FOO define in test.in after an initial build and see the resultant executable be rebuilt and see it's value changed.
The commands used to test
$ cmake -B build -G Ninja
-- The C compiler identification is Clang 11.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 11.0.0 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.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:/Program Files/LLVM/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: <some_path>
$ cmake --build build
[3/3] Linking CXX executable test_exe.exe
$ ./build/test_exe.exe
The value is 4
$ echo "#define FOO 3" > test.in
$ cmake --build build
[3/3] Linking CXX executable test_exe.exe
$ ./build/test_exe.exe
The value is 3

Related

CMake with clang shows undefined symbol, and with cl links correctly

TLDR
Im building a static library and linking it to an executable. Im generating makefiles with cmake. When I generate the makefile for cl (The compiler from visual studio) I have no problems, but when I generate the makefile for clang I get an undefined symbol.
Versions:
cmake version 3.18.1
clang version 11.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
cl version 19.26.28806 for x64
Minimal Example
I have the following structure for the proyect:
Proyect Root
│ CMakeLists.txt
│ foo.cpp
│ foo.hpp
│ main.cpp
│
└───bin
And this are the contents of the files:
foo.hpp
namespace foo {
void do_stuff(void);
}
foo.cpp
#include <foo.hpp>
namespace foo {
void do_stuff(void) {}
}
main.cpp
#include <foo.hpp>
int main(void) {
foo::do_stuff();
return 0;
}
And CMakeLists.txt
cmake_minimum_required(VERSION 3.0.0)
project(CompileAndLinkLib)
include_directories(".")
file(GLOB FOO_SRC "foo.cpp")
add_library(foo STATIC ${FOO_SRC})
add_executable(main "main.cpp")
target_link_libraries(main foo)
Correct linking
First I call vcvarsall.bat. I generate a nmake file with the following command:
cmake .. -G "NMake Makefiles"
And compile with:
nmake
The project compiles and links correctly
The undefined symbol
I generate the make file with the following command:
cmake .. -G "Unix Makefiles" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
And when I compile with make I get the following output:
Scanning dependencies of target foo
[ 25%] Building CXX object CMakeFiles/foo.dir/foo.cpp.obj
[ 50%] Linking CXX static library foo.lib
[ 50%] Built target foo
Scanning dependencies of target main
[ 75%] Building CXX object CMakeFiles/main.dir/main.cpp.obj
[100%] Linking CXX executable main.exe
lld-link: error: undefined symbol: void __cdecl foo::do_stuff(void)
>>> referenced by C:\Users\pabsa\temp\main.cpp:4
>>> CMakeFiles/main.dir/main.cpp.obj:(main)
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [main.exe] Error 1
make[1]: *** [CMakeFiles/main.dir/all] Error 2
make: *** [all] Error 2
Im not sure if im doing something wrong, like if im missing something, or if this is an error with the makefile generated by cmake.
I just had the same problem, but with Clang 13. It could be solved with specifying clang as compiler in the CMakeLists, instead of letting CMake determine it automatically.
set(CMAKE_CXX_COMPILER "clang++")
(And yes, I read your original question correct, using this:
-DCMAKE_CXX_COMPILER=clang++
as an additional argument for cmake did not work for me as well, even if it looks like it should behave the same as setting it in CMakeLists.txt)
I tested again with:
clang version 12.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
And it worked corretly. Seems like it was a problem with clang 11
You're overcomplicating things imo. What about just "cmake .. -T ClangCL && cmake --build ."? Builds fine for me:
C:\Users\vital\test\_build>cmake .. -T ClangCL
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.20348.0 to target Windows 10.0.22000.
-- The C compiler identification is Clang 14.0.5 with MSVC-like command-line
-- The CXX compiler identification is Clang 14.0.5 with MSVC-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-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:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/vital/test/_build
C:\Users\vital\test\_build>cmake --build .
MSBuild version 17.3.1+2badb37d1 for .NET Framework
Checking Build System
Building Custom Rule C:/Users/vital/test/CMakeLists.txt
foo.vcxproj -> C:\Users\vital\test\_build\Debug\foo.lib
Building Custom Rule C:/Users/vital/test/CMakeLists.txt
main.vcxproj -> C:\Users\vital\test\_build\Debug\main.exe
Building Custom Rule C:/Users/vital/test/CMakeLists.txt
C:\Users\vital\test\_build>

Covert gcc arguments to CMake file

So I am trying to learn CMake and I want to convert the following
gcc "-DARCH=\"`uname -a`\"" cli_arch.c arch.c
to a CMakeLists.txt file.
This is what I got so far:
Running cmake -DCMAKE_C_COMPILER=/usr/bin/gcc "-DARCH=\"`uname -a`\"" ..
// CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(cli_arch)
add_executable(cli_arch cli_arch.c arch.c)
The result I am getting is:
-- The C compiler identification is AppleClang 11.0.3.11030032
-- The CXX compiler identification is AppleClang 11.0.3.11030032
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /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: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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
CMake Warning:
Manually-specified variables were not used by the project:
ARCH
I am not understanding how to pass the arguments "-DARCH=\"`uname -a`\"" to CMake.
The trick is execute_process.
execute_process(COMMAND uname -s
OUTPUT_VARIABLE uname_output
OUTPUT_STRIP_TRAILING_WHITESPACE
)
add_executable(cli_arch cli_arch.c arch.c)
target_compile_definitions(cli_arch
PRIVATE "-DARCH=\"${uname_output}\""
)
I had to use uname -s since at least on my system, uname -a has a # which gcc refuses to accept in a macro via the command line.
Edit, since you changed your question. You're passing ARCH to cmake but not doing anything will it. You can pass the argument along using the same target_compile_definitions line I have above.
$ cmake -DARCH2=foo .
$ make
$ ./a
Linux
foo
The relevant part of the new CMakeLists.txt looks like this:
target_compile_definitions(a
PRIVATE "-DARCH=\"${uname_output}\""
PRIVATE "-DARCH2=\"${ARCH2}\""
)

cmake mingw-w64: strange error when trying to build

I have installed MinGW-w64 and built a simple Hello World Program. But the second time I run cmake --build . a strange error occurs.
When the Path variable is set to C:/MinGW/bin everything is fine and works. But when I set the Path to C:/msys64/mingw64/bin this happens:
PS C:\repos\hellovs\build> cmake ../ -G Ninja
-- The CXX compiler identification is GNU 10.1.0
-- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.exe
-- Check for working CXX compiler: C:/msys64/mingw64/bin/c++.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:/repos/hellovs/build
PS C:\repos\hellovs\build> cmake --build ./
[2/2] Linking CXX executable HelloVS.exe
PS C:\repos\hellovs\build> cmake --build ./
ninja: error: FindFirstFileExA(c/:/msys64/mingw64/include/c++/10.1.0): ╤шэЄръёшўхёър  ю°шсър т шьхэш Їрщыр, шьхэш яряъш шыш ьхЄъх Єюьр.
HelloVS.exe compiles normally the first time the build command is run.
Apparanteley Ninja tryies to use an invalid path. Any idea about how to fix this?
Seems like invalid dependencies have been generated:
PS C:\repos\hellovs\build> ninja -t recompact
PS C:\repos\hellovs\build> ninja -t deps
CMakeFiles/HelloVS.dir/main.cpp.obj: #deps 136, deps mtime 6109023486207704 (VALID)
../main.cpp
C/:/msys64/mingw64/include/c++/10.1.0/iostream
C/:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/c++config.h
C/:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/os_defines.h
C/:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/cpu_defines.h
C/:/msys64/mingw64/include/c++/10.1.0/pstl/pstl_config.h
C/:/msys64/mingw64/include/c++/10.1.0/ostream
...
It's a GCC bug.
MSYS2 maintainers decided to not wait for the upstream and patched it.
Run pacman -Syuu from MSYS2 shell to update your packages.

Cmake build failed with CMAKE_AR-NOTFOUND (cr exe not found)

cmake build failed with
CMAKE_AR-NOTFOUND cr libperfutils.a
When i checked build folder ar is not set.
x86_64-linux\gtest-native\1.7.0-r5\build\CMakeCache.txt
CMAKE_AR:FILEPATH=CMAKE_AR-NOTFOUND
//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++
How to set ar in cmake ?
Wheni see the cmake config below output . cmake automatically finding the g++
& why it not detecting ar
-- The CXX compiler identification is GNU 4.8.4
-- Check for working CXX compiler: g++
-- Check for working CXX compiler: g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
When i check ar in machine manually its available.
/usr/bin/ar
CMake should have been able to detect /usr/bin/ar by itself, but you can manually override this, with the -D CMAKE_AR=/usr/bin/ar option.
Here's the list of useful variables:
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/Useful-Variables
cmake ar should set in cmake lib build ,
temperorly solved the issue by manally setting in my local Cmake file
set( CMAKE_AR "${AR}" CACHE FILEPATH "Archiver" )

How can I make a library find Eigen with CMake in macOS?

I am trying to compile my project with CMake which includes the Ceres Solver library. I'm using macOS Sierra with Xcode 8.1 dev tools.
I installed the library with Homebrew (brew install ceres-solver). I downloaded and tested the binary manually (http://ceres-solver.org/building.html#mac-os-x), and that works just fine. But I can't include it in my own project because it can't seem to find Eigen. Here is a complete example:
ceres-test/CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
project(CeresTest)
find_package(ceres REQUIRED)
add_executable(
TestCeres
src/test_ceres.cpp
)
target_link_libraries(
TestCeres
ceres
)
ceres-test/src/test_ceres.cpp
#include <iostream>
#include "ceres/ceres.h"
int main(int argc, char** argv) {
std::cout << "Works." << std::endl;
return 0;
}
How I compile it:
mkdir build
cd build
cmake ..
make
Full output:
me: ceres-test $ mkdir build
me: ceres-test $ cd build/
cmake
me: build $ cmake ..
-- The C compiler identification is AppleClang 8.0.0.8000042
-- The CXX compiler identification is AppleClang 8.0.0.8000042
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/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 required Ceres dependency: Eigen version 3.2.10 in /usr/local/include/eigen3
-- Found required Ceres dependency: Glog in /usr/local/include
-- Found Ceres version: 1.11.0 installed in: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/me/Tests/ceres-test/build
make
me: build $ make
Scanning dependencies of target TestCeres
[ 50%] Building CXX object CMakeFiles/TestCeres.dir/src/test_ceres.cpp.o
In file included from /Users/me/Tests/ceres-test/src/test_ceres.cpp:3:
In file included from /usr/local/include/ceres/ceres.h:37:
In file included from /usr/local/include/ceres/autodiff_cost_function.h:132:
In file included from /usr/local/include/ceres/internal/autodiff.h:145:
/usr/local/include/ceres/jet.h:165:10: fatal error: 'Eigen/Core' file not found
#include "Eigen/Core"
^
1 error generated.
make[2]: *** [CMakeFiles/TestCeres.dir/src/test_ceres.cpp.o] Error 1
make[1]: *** [CMakeFiles/TestCeres.dir/all] Error 2
make: *** [all] Error 2
I have no idea how to resolve this. None of the solutions I found online helped. CMake seems to be finding the Eigen library just fine, so I'm not sure how to add it in.
On a side note I cannot include "Eigen/Core" directly either, but the tests that I was able to compile do include it and those are fine. I'm not familiar how to deal with these kinds of problems with CMake.
Edit: I can get it to compile if I include it as "eigen3/Eigen/Core" but I can't change the source code for Ceres.
Fixed with
include_directories(${EIGEN_INCLUDE_DIR})
in the CMakeLists....
For my mac mini m1.
I found the eigen library through
brew link --overwrite eigen.
It's located on
/opt/homebrew/Cellar/eigen/3.4.0_1/include/eigen3