Enable compiler warnings in Kdevelop - makefile

I'm using Kdevelop for a simple C++ project. I know that Kdevelop uses CMake to build the project, but the only thing that I known about CMake is that if I add a new .cpp source file in my project, I have to add it also in CMakeLists.txt.
Now I'm trying to enable tha gcc compiler warnings (i.e. compiling with g++ -Wall ...).
Does Kdevelop have a compiler settings section, or I have to edit directly the Makefile or another CMake settings file?

You can add compiler flags in CMake by adding the following command to your CMakeLists.txt:
list( APPEND CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")

Related

How to add CFLAGS and CXXFLAGS and LDFLAGS to file.cmake? [duplicate]

I am using the arm-linux-androideabi-g++ compiler. When I try to compile a simple "Hello, World!" program it compiles fine. When I test it by adding a simple exception handling in that code it works too (after adding -fexceptions .. I guess it is disabled by default).
This is for an Android device, and I only want to use CMake, not ndk-build.
For example - first.cpp
#include <iostream>
using namespace std;
int main()
{
try
{
}
catch (...)
{
}
return 0;
}
./arm-linux-androideadi-g++ -o first-test first.cpp -fexceptions
It works with no problem...
The problem ... I am trying to compile the file with a CMake file.
I want to add the -fexceptions as a flag. I tried with
set (CMAKE_EXE_LINKER_FLAGS -fexceptions ) or set (CMAKE_EXE_LINKER_FLAGS "fexceptions" )
and
set ( CMAKE_C_FLAGS "fexceptions")
It still displays an error.
Note: Given CMake evolution since this was answer was written in 2012, most of the suggestions here are now outdated/deprecated and have better alternatives.
Suppose you want to add those flags (better to declare them in a constant):
SET(GCC_COVERAGE_COMPILE_FLAGS "-fprofile-arcs -ftest-coverage")
SET(GCC_COVERAGE_LINK_FLAGS "-lgcov")
There are several ways to add them:
The easiest one (not clean, but easy and convenient, and works only for compile flags, C & C++ at once):
add_definitions(${GCC_COVERAGE_COMPILE_FLAGS})
Appending to corresponding CMake variables:
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}")
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${GCC_COVERAGE_LINK_FLAGS}")
Using target properties, cf. doc CMake compile flag target property and need to know the target name.
get_target_property(TEMP ${THE_TARGET} COMPILE_FLAGS)
if(TEMP STREQUAL "TEMP-NOTFOUND")
SET(TEMP "") # Set to empty string
else()
SET(TEMP "${TEMP} ") # A space to cleanly separate from existing content
endif()
# Append our values
SET(TEMP "${TEMP}${GCC_COVERAGE_COMPILE_FLAGS}" )
set_target_properties(${THE_TARGET} PROPERTIES COMPILE_FLAGS ${TEMP} )
Right now I use method 2.
In newer versions of CMake you can set compiler and linker flags for a single target with target_compile_options and target_link_libraries respectively (yes, the latter sets linker options too):
target_compile_options(first-test PRIVATE -fexceptions)
The advantage of this method is that you can control propagation of options to other targets that depend on this one via PUBLIC and PRIVATE.
As of CMake 3.13 you can also use target_link_options to add linker options which makes the intent more clear.
Try setting the variable CMAKE_CXX_FLAGS instead of CMAKE_C_FLAGS:
set (CMAKE_CXX_FLAGS "-fexceptions")
The variable CMAKE_C_FLAGS only affects the C compiler, but you are compiling C++ code.
Adding the flag to CMAKE_EXE_LINKER_FLAGS is redundant.
The preferred way to specify toolchain-specific options is using CMake's toolchain facility. This ensures that there is a clean division between:
instructions on how to organise source files into targets -- expressed in CMakeLists.txt files, entirely toolchain-agnostic; and
details of how certain toolchains should be configured -- separated into CMake script files, extensible by future users of your project, scalable.
Ideally, there should be no compiler/linker flags in your CMakeLists.txt files -- even within if/endif blocks. And your program should build for the native platform with the default toolchain (e.g. GCC on GNU/Linux or MSVC on Windows) without any additional flags.
Steps to add a toolchain:
Create a file, e.g. arm-linux-androideadi-gcc.cmake with global toolchain settings:
set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++)
set(CMAKE_CXX_FLAGS_INIT "-fexceptions")
(You can find an example Linux cross-compiling toolchain file here.)
When you want to generate a build system with this toolchain, specify the CMAKE_TOOLCHAIN_FILE parameter on the command line:
mkdir android-arm-build && cd android-arm-build
cmake -DCMAKE_TOOLCHAIN_FILE=$(pwd)/../arm-linux-androideadi-gcc.cmake ..
(Note: you cannot use a relative path.)
Build as normal:
cmake --build .
Toolchain files make cross-compilation easier, but they have other uses:
Hardened diagnostics for your unit tests.
set(CMAKE_CXX_FLAGS_INIT "-Werror -Wall -Wextra -Wpedantic")
Tricky-to-configure development tools.
# toolchain file for use with gcov
set(CMAKE_CXX_FLAGS_INIT "--coverage -fno-exceptions -g")
Enhanced safety checks.
# toolchain file for use with gdb
set(CMAKE_CXX_FLAGS_DEBUG_INIT "-fsanitize=address,undefined -fsanitize-undefined-trap-on-error")
set(CMAKE_EXE_LINKER_FLAGS_INIT "-fsanitize=address,undefined -static-libasan")
You can also add linker flags to a specific target using the LINK_FLAGS property:
set_property(TARGET ${target} APPEND_STRING PROPERTY LINK_FLAGS " ${flag}")
If you want to propagate this change to other targets, you can create a dummy target to link to.
This worked for me when I needed a precompile definition named "NO_DEBUG":
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14 -DNO_DEBUG")
Then from code
#ifdef NO_DEBUG
.....
With CMake 3.4+, APPEND can be used with the string command to add flags.
string(APPEND CMAKE_EXE_LINKER_FLAGS " -fexceptions")

CMake: different compiler flags during configuration?

CMake 3.9, arm-gcc 5.4.1, Linux / OSX:
I'm enabling stack smashing protection by adding -fstack-protector-strong to my compiler flags. This instructs gcc to look for specially-named symbols in the hard-coded libraries libssp.a and libssp_nonshared.a.
These libraries exist in my application as part of the build, but they do not yet exist when CMake is interrogating my compiler during the configuration phase.
This causes CMake to fail, which makes sense:
[2/2] Linking CXX executable cmTC_0f43d
FAILED: cmTC_0f43d
/path/to/arm-none-eabi-g++ -fstack-protector-strong
CMakeFiles/cmTC_0f43d.dir/testCXXCompiler.cxx.obj -o cmTC_0f43d
/path/to/arm-none-eabi/bin/ld: cannot find -lssp_nonshared
/path/to/arm-none-eabi/bin/ld: cannot find -lssp
Is there any way to:
Tell CMake to not use -fstack-protector-strong during compiler interrogation?
Provide an empty "dummy" version of libssp and libssp_nonshared during interrogation?
Skip compiler interrogation entirely? (This is a custom toolchain.)
Or any other way to work around this?
Tell CMake to not use -fstack-protector-strong during compiler interrogation?
Just add this compiler flag after the project() call, when CMake checks a compiler.
project(MyProject)
# ...
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fstack-protector-strong")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fstack-protector-strong")
Instead of appending the flag to CMAKE_*_FLAGS variable, you may also add it via add_compile_options command:
project(MyProject)
# ...
add_compile_options("-fstack-protector-strong")
In my case, option 3 turned out to be easy. In my toolchain CMake file, I simply added:
set(CMAKE_C_COMPILER_WORKS ON)
set(CMAKE_CXX_COMPILER_WORKS ON)
And now CMake doesn't waste any time interrogating the features of my compiler.
This works in my specific case (embedded systems firmware), but it would be nice how to get CMake and -fstack-protector-strong to work on non-embedded programs as well.

cmake keeps adding the std=gnu++11 option

I'm trying to compile a project in C++ using cmake, and in the page of the project they tell me that it will crash if I don't add the standard 98. (I'm on a mac)
I've tried all I found on the internet and I could manage to make the cmake use the option -std=c++98 but it also adds -DNDEBUG -std=gnu++11. (I saw it using the make VERBOSE=1 option)
I would like to get rid of that. Using the --trace option I could see that the option is set in a file which is in the cellar folder, that is, is something that has to do with cmake itself and not in the CMakeList.txt file im using.
How can I solve this problem?
If it can help the code I'm trying to compile is this:
SAMoS
Thank you.
UPDATE:
with the --trace option I was able to see that the -std=gnu++11 option was selected in the file:
/usr/local/Cellar/cmake/3.9.4.1/share/cmake/Modules/Compiler/GNU-CXX.cmake
which can be seen here GNU-CXX.cmake
If I eddit that file in a way that every if sets the option to -std=c++98 then, the cmake complains giving me the next error:
CMake Error in src/CMakeLists.txt:
The compiler feature "cxx_nullptr" is not known to CXX compiler
"GNU"
version 7.2.0.
I don't know what else can I try...
You need to set the language standard:
set(CMAKE_CXX_STANDARD 98)
Depending on the compiler, it may enable extensions as well. To disable the GNU extensions also add:
set(CMAKE_CXX_EXTENSIONS OFF)
Note that setting this options does so only for the specified target and dependent targets.
Have take a look at this section of the CMake manual for more information on compiler features. Do note however, using this
The inclusion of VTK is polluting SAMoS's CMake scope with the C++11 requirement. You can test this by disabling VTK on your cmake command line.
$ cd ~SAMoS
$ mkdir build; cd build
$ cmake -DVTK_FOUND=FALSE ../
[...]
$ make VERBOSE=1
[...]
Scanning dependencies of target samos
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/CMakeFiles/samos.dir/build.make src/CMakeFiles/samos.dir/build
[ 1%] Building CXX object src/CMakeFiles/samos.dir/samos.cpp.o
cd /Users/nega/SAMoS/build/src && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DCGAL_USE_GMP -DCGAL_USE_MPFR -DHAS_CGAL -isystem /usr/local/include -I/include -I/Users/nega/SAMoS/src/constraints -I/Users/nega/SAMoS/src/dump -I/Users/nega/SAMoS/src/log -I/Users/nega/SAMoS/src/integrators -I/Users/nega/SAMoS/src/messenger -I/Users/nega/SAMoS/src/parser -I/Users/nega/SAMoS/src/potentials -I/Users/nega/SAMoS/src/potentials/external -I/Users/nega/SAMoS/src/potentials/pair -I/Users/nega/SAMoS/src/potentials/bond -I/Users/nega/SAMoS/src/potentials/angle -I/Users/nega/SAMoS/src/system -I/Users/nega/SAMoS/src/utils -I/Users/nega/SAMoS/src/aligner -I/Users/nega/SAMoS/src/aligner/pair -I/Users/nega/SAMoS/src/aligner/external -I/Users/nega/SAMoS/src/population -I/Users/nega/SAMoS/src -I/Users/nega/SAMoS/build -DNDEBUG -o CMakeFiles/samos.dir/samos.cpp.o -c /Users/nega/SAMoS/src/samos.cpp
You'll notice there's no -std=gnu++11 flag anymore. Of course, since it looks like you're GCC version 7.2, you'll still want your set CMAKE_CXX_STANDARD to 98 since gcc-7.2 uses C++11 by default. (Or maybe it's C++14 now...) You can do this on your cmake command line.
$ cmake -DUSE_VTK=FALSE -DCMAKE_CXX_STANDARD=98 ..
CMake will then add -std=gnu++98 to its compile commands.
If you can't live without VTK, then you'll need to send a bug report upstream asking the SAMoS folks to clarify their documentation, or fix how they're including VTK.

How to create a makefile for Keystone library using cmake? [duplicate]

Work on Ubuntu 16
I used g++ main.cpp -lpq command for compiler my small project. Now I use Clion and wanna do same what I do with g++. But I can't add compiler flags in cmake file and get compile error.
cmake_minimum_required(VERSION 3.5.1)
project(day_g)
set(CMAKE_CXX_FLAGS "-lpq")
add_definitions(-lpq)
message("CMAKE_CXX_FLAGS is ${CMAKE_CXX_FLAGS}")
set(CMAKE_CXX_STANDARD 11)
set(SOURCE_FILES main.cpp)
add_executable(day_g ${SOURCE_FILES})
Also I run only cmake file and get CMAKE_CXX_FLAGS with -lpq flag.
CMAKE_CXX_FLAGS is -lpq
-- Configuring done
-- Generating done
How properly add compiler flags to cmake file?
Flag -l is for linker, not for compiler. This flag is used for link with libraries. CMake has special command target_link_libraries for that purpose:
target_link_libraries(day_g pq)
-lq is not a compiler flag (CFLAGS) but a linker flag.
To pass a library in a CMake project you should use:
target_link_libraries(target_name libraries...)
Note that if you specify 'q' as library the project will link with libq.a or, if you are on windows q.dll.
... in your CMakeLists.txt the correct line to add is:
target_link_libraries(day_g pq)
Note also that when you add a CFLAG you should also "remember" the previous ones that may be added by libraries or by your platform, ie:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3")
To check the exact flags cmake is passing to compiler or linker you can always run, from the build directory, the following command:
make VERBOSE=1

Using CMakeLists causes error while compiling fine in commandline

I am compiling my code, in which I use posix threads in C.
I am using CLion and its CMakeLists.txt:
cmake_minimum_required(VERSION 3.7)
project(Test)
set(CMAKE_C_STANDARD 99)
add_definitions(-lpthread)
set(SOURCE_FILES main.c)
add_executable(Test ${SOURCE_FILES})
I am getting errors (eg: undefined reference tosem_init'`).
The proposed suggestion for solution is adding -lpthread compiler flag, but I already added it.
I compiled the same code from commandline:
gcc main.c -lpthread
It compiles without any problem.
What can be a possible problem/solution for this?
Remove add_definitions(-lpthread) entirely since pthread is not a definition, but a library dependency.
Add after add_executable():
target_link_libraries(Test pthread)
Also, if you want to see what commands CMake is using without having to examine its files, you can use it on the command line with cmake -DCMAKE_VERBOSE_MAKEFILE=ON ....
Btw, always prefer all the target_* commands, like target_compile_definitions() instead of older style add_definitions(). This keeps your project properties and dependencies clean and minimizes interference between different targets.
If after the above changes your code still does not compile, then it is highly likely the code itself is wrong (nothing to do with CMake).

Resources