I've been working on adding functionality to a C++ library. The library is compiled by using CMake. It has a complex set of dependencies. I have a C++ test file that runs code relating to the library. Let the compiled file be test.cpp, its executable test.
So far, I've been debugging by adding "cout" statements to the library files. I frequently get segmentation faults, but can usually figure it out by inspection. Obviously, this is inefficient. I want to see where the code fails, by using gdb. Via this stackoverflow post, I tried adding debug flags to my cmake, but when I run gdb on test and do bt, I don't get comprehensive info. I simply get the name of the function in the library where the code fails, not the exact line.
Anyone know how to get the gdb information?
While adding the respective compiler flags manually will work, it is not the most convenient way of doing so. As suggested by #ruslo, you should use the following command line instead for getting debug support:
cmake -DCMAKE_BUILD_TYPE=Debug <path_to_source>
There are several reasons for this:
Compiler flags are not portable. -g -O0 will work on gcc, but what about other compilers? One of CMake's main strengths is to make portability easy, so you should not throw it out of the window easily.
Multi-configuration generators (like most IDE generators) allow to use multiple profiles at once. You would not want to force users of those IDEs to compile without optimizations even though they selected a Release profile, would you?
Changes to CMAKE_CXX_FLAGS are global. This becomes especially nasty once you have to compose multiple projects together. If you absolutely need to manually give compiler flags, use target_compile_options for this purpose.
Last but not least: Setting CMAKE_BUILD_TYPE is the idiomatic solution to this problem. It is the one right tool for solving it and people familiar with CMake (granted, there are not too many around of those...) will be surprised if you solve it using a non-idiomatic workaround.
I've figured it out. They key is to add the "-g" flag to
SET (CMAKE_C_FLAGS ...
and
SET(CMAKE_CXX_FLAGS ...
to the CMakeLists.txt file.
Related
I have a CMake project which includes a single target that includes both C++(.cpp) and CUDA C++(.cu) files. However I have some questions which I failed to address.
At the top of my CMakeLists.txt I have:
project(my-project CUDA CXX)
For the ones confused: Yes, CMake 3.8 makes CUDA C++ an intrinsically supported language. So there is no longer need to use things like cuda_add_executable() and sorcery like that. Everything works just fine by using standard and native CMake commands. Also, apparently you can set more than one languages in CMake's project() command. See: https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/
My problem now is that I want to set different compiler flags for the different compilers in a CMake way (i.e., with the target_compile_options() command). The first solution I can think of is:
add_compile_options(my_target
PRIVATE
$<$<COMPILE_LANGUAGE:CXX>:-Wsign-conversion>
$<$<COMPILE_LANGUAGE:CUDA>:-arch=compute_30>
)
However, I find this code a bit ugly. The other option I can think of would be to create two separate targets, one for the .cpp files and one for the .cu files. Then I will be able to set the compiler options separately for the GCC and NVCC targets.
Both of the above solutions seem to work, but I am trying to figure out which is the better way. Any suggestions? Pros and cons?
I am also having trouble with the first solution when I want to include multiple compiler flags. What is the proper way of splitting them? Just use space between the different flags? And what if I want to span the expression on multiple lines? If I try to do so in any way, CMake gives me syntax errors.
Finally, I want to avoid manually altering CMAKE_CXX_FLAGS and CMAKE_CUDA_FLAGS.
Thank you in advance
I agree with #OutOfBound in comments, the simplest solution is to split your code in sub project(s). This way you can control each project flags independently, and even build multiple .cu files with different flags (if needed). If this becomes more complex, you might also want to build kernels with nvcc and load them with cuModuleLoad*().
I am building an open source project (kst, v2.0.8) that uses CMake. I am using CMake v2.8.12.2 and MSVC 2008 as a compiler and am generating NMake makefiles to build it on the command line. I can get it to build successfully with this setup. These versions are mandated so I cannot currently use a later version of CMake or MSVC.
I need to be able to perform a source code analysis of kst using HP's Fortify and to be able to use it from the command line it works in one of two ways:
Touchless mode where it creates it's own "cl.exe", sets the path to it before the path to the real cl.exe and therefore gets launched during build.
Set the compiler in the makefile to the Fortify command line, e.g. sourceanalyzer -b build_id cl instead of cl.
Either way I need to force the compiler that cmake generates into its makefiles to be something that cmake does not automatically detect.
I've tried setting the compiler when running cmake following the same method in this question but cmake still insists on putting the full path to the MSVC cl.exe in the makefiles.
cmake -DCMAKE_C_COMPILER=cl -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER=cl -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I also tried setting the compiler to invoke Fortify but when cmake tests the compiler it fails saying that it cannot find the compiler. (I have also tried this without the FORCED=ON arguments and in that case it says the compiler fails.)
cmake -DCMAKE_C_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I could probably search and replace all the compiler invocations in the makefiles but I'd have to remember to do that after every cmake, and it would be tedious seeing as there are multiple projects / makefiles / calls to cl (rather than defining a CC variable in the makefile). I'd rather have a way to make cmake use the desired compiler right from the offset.
UPDATED: Testing showed the original suggested approach didn't work as expected on at least some platforms. It seems using a wrapper script is likely the way to go.
If you really want to force a particular compiler and by-pass CMake's compiler checks, the CMakeForceCompiler module may be what you are looking for. That link to the CMake docs contains a trivial toolchain file example which shows how to use a specific compiler invoked as a simple command with no path. Unfortunately, CMake still converts this to an absolute path, so on its own, this won't solve your problem. You could, however, use a toolchain file to point at a wrapper script and use CMakeForceCompiler to bypass the compiler checks. This combination should yield the behaviour you've asked for, but note that CMakeForceCompiler is now deprecated.
Note that when using the CMakeForceCompiler module, you take on a bit more responsibility for telling CMake information, notably the compiler ID of the particular compiler you want to force using, but from the CMake docs it seems pretty clear this will just be MSVC in your case.
To use a toolchain file, invoke CMake with a -DCMAKE_TOOLCHAIN_FILE=path/to/file option pointing at your own custom toolchain file. The CMake docs have a specific section covering the use of toolchains, although it does gloss over some of the important nitty gritty details.
As mentioned in #Tsyvarev's comment, the use of a wrapper script is likely to be your best way of dealing with this. That wrapper script just needs to forward the call to the usual compiler command without specifying a path. You then take responsibility for ensuring the command will be on your PATH when you do a build. Something as simple as the following should suffice as a wrapper batch file on Windows (untested):
cl %*
Now, you can control whether the Visual Studio compiler or Fortify gets invoked purely by the PATH the build sees. Personally, I think this is a bit fragile, but it's what you asked for. ;)
As a more robust alternative, is it possible to use two completely separate builds? If so, then I'd recommend that as a better alternative. Build one with the default Visual Studio compiler as normal and for the other build, use a toolchain file to point at the Fortify compiler to get CMake to bypass its compiler checks. That way you aren't relying on the build environment being set up a particular way.
I've bumped into the following annoying issue. I installed g++ via macports on OSX, everything works fine. However, cmake still detects clang++ as the cpp compiler. Therefore, I end up putting
export CXX=/opt/local/bin/g++
in my profile. Now, cmake correctly detects g++ as the compiler. The problem is that all the system headers that I include with
INCLUDE_DIRECTORIES(SYSTEM "/path/to/system/header)
are included as regular headers. In other words, I am getting a whole bunch of warnings (-Wall) which I'd very much like to suppress, since I don't care about warnings in system headers like Boost or Eigen.
Any idea how to address this issue? It's driving me crazy, and I am completely puzzled why adding CXX in the profile results in this behaviour. If I remove the export CXX from my profile and manually set CMAKE_CXX_COMPILER to g++ in the CMakeLists.txt then everything is fine, no more warnings for system files.
I finally figured out a solution, from a somehow randomly found post: http://www.cmake.org/pipermail/cmake/2011-June/044769.html. For some reason, the SYSTEM directive was ignored. Setting
SET(CMAKE_INCLUDE_SYSTEM_FLAG_CXX "-isystem ")
solves it, no more warnings generated for system files.
This is a very peculiar issue that appears only on OS X. On all other systems I tested, INCLUDE_DIRECTORIES(SYSTEM "/path/to/system/header") adds the headers as system headers, without any need to use the SET above.
Using export CXX=/opt/local/bin/g++ with several other system variables not adapted seems a little bit unorthodox, so the weird behavior is maybe not surprising.
I suggest you configure from scratch (=from a clean build directory) your project from cmake-gui, the menu allows you to specify the path to the compiler(s) you want to use. You can also use a custom tool-chain file. I suggest you use cmake-gui, it offers a couple of choice that might solve your problem.
Once you get it right, you can document the equivalent command line instruction for other people building your project.
I have both C++ and C files in my project. I have separate and different compile flags settings for each, using CMAKE_CXX_FLAGS and CMAKE_C_FLAGS. How do I create different linker flags for each?
It would have been nice if something like CMAKE_CXX_EXE_LINKER_FLAGS and CMAKE_C_EXE_LINKER_FLAGS existed, but there is only CMAKE_EXE_LINKER_FLAGS.
There are
CMAKE_CXX_LINK_EXECUTABLE
CMAKE_C_LINK_EXECUTABLE
that look like they can solve your problems.
Keep in mind that you are getting into compiler and platform specific stuff, it's up to you to put the right combinations of conditional to select the right set of macros, if you need a multiplatform, multicompiler, project.
Build rules
It turns out in CMake version 3.0.2 at least, there are the following variables, CMAKE_C_LINK_FLAGS and CMAKE_CXX_LINK_FLAGS, used in ./share/cmake-3.0/Modules/CMakeCXXInformation.cmake.
They were not documented anywhere I had looked, and are not present in the generated files or cache, hence why I didn't find them. But they appear to do what I need.
Hopefully, CMake will continue to support them, and not remove them suddenly without warning, as is sometimes the case with undocumented features.
I have got my first project for this semester and I have been asked to submit it with a makefile. The literature available on the internet is a bit overwhelming and combined with my laziness, I came to stackoverflow for simple answers. I have found this answer by Brendan Long as a good place to start with.
The example he gives is:
all: a3driver.o
g++ -o a3driver a3driver.o
a3driver.o: a3driver.cpp
g++ -c a3driver.cpp
which i understand. This looks exactly like the make files I have seen on a Unix system and which i used to compile c++ files(only used, did not need to understand).
Then i search further and an answer to this question suggests using CMake which is completely different from the code I have pasted above.
So my question at this stage is which direction should i take? Should I learn about the CMake or the GNUMake? I only intend to work on C++ files for now.
Only you can answer this question because it depends heavily on your needs. Cmake is a "build control file generator", not a build control program. It doesn't actually build code: instead it will create a makefile, or a Visual Studio / Xcode / Eclipse project file, etc. You then use that build program (make, Visual Studio, XCode, Eclipse) to actually build the code.
Cmake is good if you need to support all those different types of builds across all those different architectures using their native build environments. If you're happy to use make on whichever architecture you need to build on (GNU make runs on all of those as well and all those IDEs except possibly Visual Studio have good integration with native make) then using make directly is fine. GNU make has lots of advanced features which make it very flexible.
I don't really agree with esseks assessment of the autotools although I know it's a very common opinion. Also note that automake itself does not use unusual, verbose syntax: automake files are just makefiles. However they have to be processed, and autoconf is how that's done... autoconf is more obscure although not as bad as people make it out to be, depending on your needs. This isn't the place for that discussion however.
I personally find cmake format even more annoying and strange than autotools, and it doesn't meet my needs in many ways (for example it's support for cross-compilation is not as good as autotools'). However I have to say its ability to generate native project files is really excellent--if you need it.
If you need a really really dead simple makefile for compiling one or few files only, then you are done with:
compile:
g++ myprogram.cpp -o myprogram
(note that lines must be indented with tab, not spaces).
If you need flexibility, you are on the right path with CMake. I suggest you to explore CMake, starting from their good tutorial or a simple example -- as the basics are simpler to undestand from code rather than learn from manual.
My personal opionion is to avoid GNU Automake (colloquially known as Autohell) because of the unusual, verbose syntax that sometimes scares beginners and tricks more experienced users.
EDIT: CMake is not used to compile, rather, it can generate makefiles for you, starting from a synthetic description of the project (where are the files to be compiled? What libraries are required? etc.). And it does this by checking for libraries, identifying compiler and carrying out other sanity check you would need to code by yourself otherwise.