I use NDK and cmake for my Android app. Typical cmake commande is like this:
cmake -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=x86 -DANDROID_PLATFORM=android-24
I wonder what is the meaning of the -D ?
Does cmake commands work without -D ?
cmake -CMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake -ANDROID_ABI=x86 -ANDROID_PLATFORM=android-24
What is the impact on the final build?
Thanks
Related
I use CMake with GNU Make and would like to see all commands exactly (for example how the compiler is executed, all the flags etc.).
GNU make has --debug, but it does not seem to be that helpful are there any other options? Does CMake provide additional flags in the generated Makefile for debugging purpose?
When you run make, add VERBOSE=1 to see the full command output. For example:
cmake .
make VERBOSE=1
Or you can add -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON to the cmake command for permanent verbose command output from the generated Makefiles.
cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON .
make
To reduce some possibly less-interesting output you might like to use the following options. The option CMAKE_RULE_MESSAGES=OFF removes lines like [ 33%] Building C object..., while --no-print-directory tells make to not print out the current directory filtering out lines like make[1]: Entering directory and make[1]: Leaving directory.
cmake -DCMAKE_RULE_MESSAGES:BOOL=OFF -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON .
make --no-print-directory
It is convenient to set the option in the CMakeLists.txt file as:
set(CMAKE_VERBOSE_MAKEFILE ON)
Or simply export VERBOSE environment variable on the shell like this:
export VERBOSE=1
cmake --build . --verbose
On Linux and with Makefile generation, this is likely just calling make VERBOSE=1 under the hood, but cmake --build can be more portable for your build system, e.g. working across OSes or if you decide to do e.g. Ninja builds later on:
mkdir build
cd build
cmake ..
cmake --build . --verbose
Its documentation also suggests that it is equivalent to VERBOSE=1:
--verbose, -v
Enable verbose output - if supported - including the build commands to be executed.
This option can be omitted if VERBOSE environment variable or CMAKE_VERBOSE_MAKEFILE cached variable is set.
Tested on Cmake 3.22.1, Ubuntu 22.04.
If you use the CMake GUI then swap to the advanced view and then the option is called CMAKE_VERBOSE_MAKEFILE.
I was trying something similar to ensure the -ggdb flag was present.
Call make in a clean directory and grep the flag you are looking for. Looking for debug rather than ggdb I would just write.
make VERBOSE=1 | grep debug
The -ggdb flag was obscure enough that only the compile commands popped up.
CMake 3.14+
CMake now has --verbose to specify verbose build output. This works regardless of your generator.
cd project
cmake -B build/
cmake --build build --verbose
It's worth noting however Xcode may not work with --verbose
Some generators such as Xcode don't support this option currently.
Another option it to use the VERBOSE environment variable.
New in version 3.14.
Activates verbose output from CMake and your build tools of choice when you start to actually build your project.
Note that any given value is ignored. It's just checked for existence.
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE will generate a file with all compilation commands.
This file is required by some LSP to know how to compile a source file out of the box, but it could also help for debugging compilation problems.
The output file is named ${CMAKE_BINARY_DIR}/compile_commands.json.
I've been trying to build wxwidget 3.1.5 on Windows 10 using CMake.
I simply used the command recommended on the official website:
cmake -G "MinGW Makefiles" ..\wxWidgets-3.1.5\ -DwxBUILD_TESTS=ALL
cmake --build .
It went smoothly until a message popped up
[100%] Building CXX object tests/headers/CMakeFiles/test_headers.dir/__/__/__/__/tests/allheaders.cpp.obj
In file included from D:/tools/wxwidget/wxWidgets-3.1.5/include/wx/platform.h:343,
from D:/tools/wxwidget/wxWidgets-3.1.5/include/wx/defs.h:45,
from D:/tools/wxwidget/wxWidgets-3.1.5/include/wx/wxprec.h:12,
from D:\tools\wxwidget\wxWidgets-3.1.5\tests\testprec.h:4,
from D:\tools\wxwidget\wxWidgets-3.1.5\tests\allheaders.cpp:433:
D:/tools/wxwidget/wxWidgets-3.1.5/include/wx/wxcrtbase.h:228:39: error: redundant redeclaration of 'size_t wcsnlen(const wchar_t*, size_t)' in same scope [-Werror=redundant-decls]
228 | wxDECL_FOR_MINGW32_ALWAYS(size_t, wcsnlen, (const wchar_t*, size_t))
Anybody knows how to cope with it? Thanks in advance!
WxWidgets already provides makefile for you. All you need to do is use it 😀:
cd WxWidgets-3.1.5\build\msw
mingw32-bin.exe -f makefile.gcc BUILD=debug
The question
Debug vs Release in CMake
indicates that
cd ~/codebase
mkdir Release
cd Release
cmake -DCMAKE_BUILD_TYPE=Release ..
make
Will create the Makefile in release, and build the binary there. The intermediate .o files will be in a subdirectory of this.
However, when I do this with my project, CMake ignores the PWD that it is started from. The final target is always the directory ~/codebase/ which contains CMakeList.txt.
In the cmake-gui tool, I specified the source and build directories to be the same directory, the FQN to codebase
I'm new to CMake, and don't know how to get this to work as I expect. What should I modify to get this work as expected?
If you are using a single configuration generator (Ninja/Unix-Makefiles)
Then you need a build folder for each configuration.
Like this:
# Configure the build
cmake -S . -B build/Debug -D CMAKE_BUILD_TYPE=Release
# Actually build the binaries
cmake --build build/Debug
For multi-configuration generators it's slightly different (Ninja Multi-Config, Visual Studio)
# Configure the build
cmake -S . -B build
# Actually build the binaries
cmake --build build --config Debug
If you are wondering why this is necessary it's because cmake isn't a build system. It's a meta-build system (IE a build system that creates build systems). This is basically the result of handling build systems that support multiple-configurations in 1 build. If you'd like a deeper understanding I'd suggest reading a bit about cmake in Craig Scott's book "Professional CMake: A Practical Guide
Note:
My examples use newer cmake cli practices.
EDIT:
That question you linked to has dangerously out of date answers...
I am an llvm beginner. I compiled llvm which checked from svn, and I got the error: unknown cmake command add_llvm_loadable_module when using cmake to create a makefile in llvmroot/lib/Transform/Hello/build. I have no idea why this occur. Is there something wrong when compiling llvm? In this case, I compiled llvm by cmake -G "Unix Makefiles" in macros. Thanks for your help.
You just mixed things up.
You should cd into ~/llvm/build and run cmake ~/llvm or cmake ... And you don't need -DCMAKE_PREFIX_PATH at all in this case.
This command will just generate build files for you. Now, if you want to build only that Hello pass instead of whole LLVM, run make help | grep Hello to find out how the corresponding target is called and then make <target>.
You should used add_llvm_library in CMakeLists.txt
like this:
add_llvm_library(My_Plugin MODULE My_Plugin.cpp PLUGIN_TOOL clang)
I'm trying to make Ninja work with CMake on FreeBSD 10.3:
cmake -GNinja ..
-- Configuring done
CMake Error:
The detected version of Ninja () is less than the version of Ninja required
by CMake (1.3).
-- Build files have been written to: /home/me/pj/_build
I have put a locally compiled (from Git tag v1.8.2) Ninja in ~/bin/ninja (which is in my $PATH).
$ cmake -version
cmake version 3.4.1
$ ninja --version
1.8.2
I also tried to add -DCMAKE_MAKE_PROGRAM=ninja and -DCMAKE_MAKE_PROGRAM=~/bin/ninja without effect.
I also tried to see if Ninja was really called (by putting a script writing a new file), and it looks like it's never called.
Is there a way to see which commands are used to to check the Ninja version?
By inspecting the generated CMakeCache.txt file, you should be able to tell which Ninja version is picked by CMake.
In CMakeCache.txt you should have something similar to:
// Path to a program.
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/ninja
which could tell which Ninja version is picked by default and whether -DCMAKE_MAKE_PROGRAM is respected or from some reason ignored.
Also, it is worth looking into the generated CMakeOutput.log and CMakeError.log files.
I would also suggest adding ninja to your PATH, hoping CMake would pick it from there.
I came across this question while getting the same error message. What I forgot to do was delete the CMakeCache.txt file before I ran cmake with the -GNinja or -DCMAKE_GENERATOR=Ninja options. So cmake was pulling the cached variable.
You can also get this error message when forgetting to call project(my_project) before calling add_library or add_executable.