I am writing a script and started working with the install command (for copying files) and it is not working. CMake configure/generate does not show any errors (i.e. it does not stop and no warnings/errors show related to this command) and the command does not seem to be working, because I don't see any files being copied.
Since I am new, I am wondering:
How can I tell that install failed (perhaps the source directory was wrong, or the destination directory was wrong)? It appears to be failing silently.
Are there error codes I can check to see what went wrong?
When is install called? When I click configure? Or when the project is built?
I am on Windows.
To the general question, there are a number of ways to get more verbose output from CMake - I just learned a third for gnarly errors:
to debug CMake recipes, I like using the message command and you can even iterate over directories and issue messages*
e.g. message( STATUS "SQLITE3_LIB: ${SQLITE3_LIB} SQLITE3_PATH: ${SQLITE3_PATH}") # prints SQLITE3_LIB and SQLITE3_PATH variables
perform verbose builds to troubleshoot your build itself
run make VERBOSE=1 (with make, ninja -v with ninja, etc.) to help you troubleshoot the process, such as cmake -DYOUR_OPTION="insert values" ~/path/to/files/ && make VERBOSE=1
if you ever find an inscrutable error, I just learned that we can run strace on the failing command - this can be a bit overwhelming, but can help when you have exhausted #1 and #2
I just used strace /usr/bin/cmake -E copy_directory $MY_SOURCE_PATH $MY_DEST_PATH to try to understand why a copy was failing
*I have used DLRdave's answer to a different question to print out the INCLUDE_DIRS:
get_property(dirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY INCLUDE_DIRECTORIES)
foreach(dir ${dirs})
message(STATUS "dir='${dir}'")
endforeach()
When you add an install command to your CMakeLists.txt, you get a new target created called "install".
In order to actually install the chosen files/targets, you need to build this install target. It's not automatically built as part of the "ALL" target.
For example, if you're using Visual Studio, the "INSTALL" target should appear in the "CMakePredefinedTargets" folder of the Solution Explorer. Just selecting this target and building it will cause the solution to be built and the selected items installed.
If any part of the build or install process fails, the notifications should then be apparent.
Related
I would like to use CMake and clang-tidy in my project, however I see that build times are quite a bit higher when I use this in all the main cmake file:
set(CMAKE_CXX_CLANG_TIDY
clang-tidy-11;
-format-style='file';
-header-filter=${CMAKE_CURRENT_SOURCE_DIR};
)
It is working well, but I don't want to have this build-time penalty every time I build the project during development. Therefore I thought I would make a separate target that builds all, but uses clang-tidy. And when I do a regular debug or release build it does not do any checking. However I don't know how to do this in Cmake. Do I make a custom target with a command "cmake --build" with a target_set_property of CMAKE_CXX_CLANG_TIDY?
This feels rather clunky, so my question is, are there other ways to do this?
however I see that build times are quite a bit higher when I use this in all the main cmake file:
You're going to have to pay for the cost of running clang-tidy sometime or another. It's essentially running the first few phases of a compiler to analyze your code and look for errors.
Setting CMAKE_CXX_CLANG_TIDY runs clang-tidy in line with your build, as you have observed.
This feels rather clunky, so my question is, are there other ways to do this?
Yes. When using the Ninja or Makefile generators, you may set -DCMAKE_EXPORT_COMPILE_COMMANDS=ON at the command line. That will create a file called compile_commands.json in your build folder that the standalone clang-tidy can read.
In sum, at the command line, you would manually run:
$ cmake -G Ninja -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
$ clang-tidy-11 -format-style=file -header-filter=. -p build
The -p flag tells clang-tidy in which directory to find your compile_commands.json.
I mean to compile example Advancing_front_surface_reconstruction from the CGAL package under Win10 + PortableApps Msys2.
For the library itself I use a precompiled package ($ pacman -Qs cgal gives local/mingw-w64-x86_64-cgal 4.14-1).
I used to be able to do that in my previous PC, see details below.
After transferring everything to a new PC (simply copying, it is PortableApps), I made a system update in Msys2 (required for other reasons).
I proceed as usual: mkdir build, cd build, ccmake ... Selecting Release mode, and verbosity ON, upon pressing g to generate files I got
CMake Error in CMakeLists.txt:
Imported target "CGAL::CGAL" includes non-existent path
"C:/building/msys64/mingw64/include"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
* The path was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and references files it does not
provide.
Upon pressing e to exit the error message, the ccmake gui was exited and there were no files generated.
After googling a bit, this suggested creating the missing dirs, which seems merely a workaround (I did not try adapting this).
I created those dirs, and then I got
CMake Error in CMakeLists.txt:
Target "CGAL::CGAL" contains relative path in its
INTERFACE_INCLUDE_DIRECTORIES:
"C:/building/msys64/mingw64/include"
How can I fix this?
I found no suitable answers around.
Possibly related links, but which I found no way of relating to a suitable solution:
https://gitlab.kitware.com/cmake/cmake/commit/634bb33f3aa3b7f2181a896c025976b52171524a
https://cmake.org/cmake/help/v3.12/manual/cmake-buildsystem.7.html
NOTE:
The same happened with other examples.
EDIT:
I do not know what changed, but now upon pressing e to exit the error message (see above) all generated files are present, including the Makefile.
So I can proceed as described below in Previous state of affairs.
This happens either with or without the missing dirs (the error message changes, but I can generate my executables).
AFAICT, the only related change is that
I have just installed packages
, mingw-w64-x86_64-eigen3 (3.3.7-1)
, mingw-w64-x86_64-suitesparse (5.4.0-1)
, mingw-w64-x86_64-lapack (3.8.0-5)
, but I would not think this should matter.
Previous state of affairs
To compile and link CGAL examples, in my previous PC, some tweaking was needed.
Compilation went fine, but linking required a couple of tweaks.
An example command line produced for linking reads
/mingw64/bin/c++.exe -O3 -DNDEBUG -Wl,--enable-auto-import CMakeFiles/reconstruction_structured.dir/reconstruction_structured.cpp.o -o reconstruction_structured.exe -Wl,--out-implib,libreconstruction_structured.dll.a -Wl,--major-image-version,0,--minor-image-version,0 /mingw64/lib/lib/libmpfr.a /mingw64/lib/lib/libgmp.dll.a /mingw64/lib/lib/libCGAL.dll.a -lC:/building/msys64/mingw64/lib/libgmp.dll.a -lC:/building/msys64/mingw64/lib/libmpfr.a
The two types of required fixes are
Replacing /mingw64/lib/lib/ with /mingw64/lib/ in every (link.txt;build.make) file.
Replacing flag -lC:/building/msys64/mingw64/lib/libgmp.dll.a with -lgmp in every link.txt file. Similarly for -lmpfr.
Run this command to find all the places in the CGAL CMake files where the erroneous directory C:/building/ is mentioned:
grep -r '/building/' /mingw64/lib/cmake/CGAL
For each instance, either delete it or replace it with something more appropriate.
(Note: I haven't tried this myself.)
This erroneous directory is a general issue with MSYS2 which I attempted to fix at one point.
My goal was to see details about an invocation of g++ called directly by cmake from the command line. I do not care about the output of make for the purposes of this question.
According to the official FAQ and the accepted answer on a related question, I should make sure CMAKE_VERBOSE_MAKEFILE:BOOL=ON is set in my generated CMakeCache.txt, by e.g. passing the commandline flag -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON. When I did that it re-queried a bunch of properties, but gave no extra information about the invocation.
However, calling cmake with the flag --verbose=1 showed me exactly what I needed.
What are these two options doing differently? Is --verbose=1 deprecated or otherwise discouraged?
No, that's not what the accepted answer and the CMake FAQ you link say, otherwise I would be surprised.
Precisely, they don't say that you should modify CMakeCache.txt. Don't modify that file, it's not a good practice, since one can easily make mistakes.
If you instead have followed exactly what both sources say, i.e.
cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON .
make
or
cmake .
make VERBOSE=1
you would have seen a verbose output from the compilation and linking phases.
Alternatively, you should achieve the same effect if you put in your CMakeLists.txt file the following line:
set( CMAKE_VERBOSE_MAKEFILE on )
The fact that you do not see output in one of the cases might due to previously cached configurations.
I suggest you do if possible out-of-source builds so that in this case you can get rid of every CMake generated files and directories by just removing the build directory.
Then you could just recreate new configurations without interference from previously generated configurations and build files.
Of course, I might be wrong and you hit a bug, but it seems unlikely.
EDIT: That's because in the configuration phase you're not compiling, i.e. you are not using a Makefile, which is what the command line option set. It's not a verbose option for the cmake command itself at any stage (configuration, compiling, installing) of the project build. It will not show extra configuration info when you do cmake . but it should show you extra information when you run the make.
So CMAKE_VERBOSE_MAKEFILE is the wrong option to set if you want to get verbose output from CMake itself.
This is what typically happens. I get source code that has cmake build scripts. I create a build subdirectory, change to it, run cmake <options> ... Depending upon the project and its dependencies I have to repeat the last step until it finds all necessary dependencies and generates makefiles. I successfully build and use the project. Few days pass, I forget about this installation. Then one day I'm trying to setup the same project on another machine and now I can't recall what exact CMake command line I used in the past to get things working.
I still have the old build directory on the old machine. Can I find the cmake command line I used in the past, by looking into some of the autogenerated files in the build directory? I was expecting CMake would just put the exact command line I used in one of these files in commented form. But if it does so, I haven't found it yet.
How can I find the original CMake command line I used?
You can't.
Original CMake command can be guessed from analysis of CMakeCache.txt
As a workaround, you could always create a simple wrapper to store the original command line used. Something along these lines:
#!/bin/bash
echo "$#" > cmake_command.log
$#
I'm attempting to debug a command line CMake failure. The same CMake file works in Qt Creator, with the arguments in the Qt Creator window matching what I have entered on the command line.
This makes me think Qt Creator is adding some extra arguments, which makes sense since the generator drop down has several options that specify architecture and CMake version.
Is there a way to get the CMake command that Qt Creator executed to produce the desired result, specifically the arguments passed to the CMake executable?
I found one post that talks about viewing the CMakeCache files to do some forensics, but this only proves there are differences, it doesn't quickly show me what arguments to change.
Try adding the following block to the end of your CMakeLists.txt and running CMake from Qt Creator again. The CMake output should list all variables that have been passed via the -D command line argument.
get_cmake_property(CacheVars CACHE_VARIABLES)
foreach(CacheVar ${CacheVars})
get_property(CacheVarHelpString CACHE ${CacheVar} PROPERTY HELPSTRING)
if(CacheVarHelpString STREQUAL "No help, variable specified on the command line.")
get_property(CacheVarType CACHE ${CacheVar} PROPERTY TYPE)
if(CacheVarType STREQUAL "UNINITIALIZED")
set(CacheVarType)
else()
set(CacheVarType :${CacheVarType})
endif()
set(CMakeArgs "${CMakeArgs} -D${CacheVar}${CacheVarType}=\"${${CacheVar}}\"")
endif()
endforeach()
message("CMakeArgs: ${CMakeArgs}")
For more info, see this answer.
This won't show what generator was selected (if any) via the -G arg. To find that, you need to look for CMAKE_GENERATOR:INTERNAL=... in your CMakeCache.txt
If this doesn't help you identify the overall problem, you should probably heed #arrowdodger's advice and post more details about the errors you're getting and your two build environments. For example, an error could be caused simply by running CMake from a subdirectory of the source tree.