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.
Related
I've been searching around for different custom pre-processor extensions and replacements, but all of them seem to come with 1 of 2 caveats:
Either 1), you generate the code as a separate build-system, them manually put the output into your real (CMake) build system, or 2) you end up losing the builtin preprocessor for GCC.
Is there really no tool that can, say, run each file it gets against some configured script, then through cpp, then pass the result to gcc?
I'd love to use something like Cog by just setting an environment variable for gcc, indicating a tool that runs Cog first and then the standard preprocessor.
Alternatively, is there a straightforward way to accomplish that in CMake, itself? I don't want to have to write a custom script for each file, especially if I have to then hard-code the compiler/preprocessor flags in each target.
edit: For clarity, I am aware of several partial/partially-applicable solutions. For example, how to tell GCC to use a different preprocessor. (Or really, to look in a different place for its own preprocessor, cc1. See: Custom gcc preprocessor) However, that leaves a lot of work to do, to modify files, and then correctly invoke the real cc1, with the correct original arguments.
Since that is effectively a constant/generic problem, I'm just surprised there is no drop in program.
Edit 2: After looking over several proposed solutions, I am not convinced there is an answer to this question. For example, if files are going to be generated by CMake, then they can't be included and browsed by the IDE - due to not yet existing.
As ridiculous as it sounds, I don't think there is any way to extend the preprocessor short of forking Gcc. Everything recommended so far, constitutes incomplete hacks.
The GCC (C++ compiler) is made for compiling C++ programs. As the C++ preprocessor is standardized within the C++ standard there is usually no need for anything like a "plugin" or "extension" there.
Don't listen to the comments, that suggest you using any exotic extension to CMake or change source code of GCC. Running source files through a different program (cog in your case) before compiling is a well known task and all major build systems support it right away.
In CMake you can use the add_custom_command function. If you need this for more than one file, you could use a CMake loop like e.g. suggested in this answer.
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'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.
I want to conditionally compile some c++ code that uses boost, and make it so it doesn't try to compile the boost dependent code if boost is not present.
Does boost have any global macro that will be defined, like __BOOST__, that I can check for?
EDIT: It's clear to me now that I have to achieve this on the makefile level. I am working on OSX lion. Using gnu make
The TYPICAL way that this is done is to use a "configuration script" or similar, that detects if the required/optional component(s) is/are present, and then selectively sets some -D options to the build system.
Obviously, if it's just your own project or a small distribution, you could do the same thing manually.
You probably also need a couple of ifdef type of choices in the Makefile if there are library files that you need.
One of the easier ways to determine if a part of boost that you need is installed is to try to compile it. If there are errors, the likely cause is that that part of boost isn't present (this obviously doesn't work if there are more important parts missing - for example, not having a compiler or standard library installed will ALSO cause a compile to fail. This is why nearly all configure type tools "start with the most basic features, and work their way up the tree of dependencies").
We have a C++ template library that has some features that depend on zlib, for example.
We selectively enable and disable features using preprocessor symbols, i.e. setting -DHAVE_ZLIB=1 on the command line.
Our CMake-based build system recognizes installed zlib and adds the according flag to the compiler.
Of course, this can also be done manually by users, using their favourite IDE or their Makefiles.
One property of the library is that the code that uses zlib is interleaved with the code not using zlib, i.e. using #include <library/header.h> should work regardless of zlib being present or not.
Currently, we #if out code that depends on zlib.
Thus, if the user tries to use something like CompressedStream, for example, the class is simply not found.
This is quite frustrating for users.
The build system warns them that zlib could not be found, but users being users either do not see this or forget it quickly.
I myself have fallen into this trap, too.
Now to my question:
What is the best way to warn the user that zlib is disable if he tries to use code requiring zlib.
The only thing I can think of is using the deprecator marker mechanisms implemented in many compilers.
Although different syntax is required for each of them, this could easily be abstracted away using preprocessor macros.
Is there any other good way?
The solution only has to work in VS >8, GCC >4.2 and LLVM.
The proper place to warn users about such things is (IMO) build system. Take a look at Ogre3D, KDE and many other projects - all of them print sort of outline after configuration of build. This outline contains information on what is found and what is not and what are consequences of this.
Even Qt don't do anyting to fix this. There is option to build Qt with STL support and if it's not built such way, there are no warnings or whatever, only compile errors regarding undefined methods. So, i think, there is no way to warn user about such things during compile phase.