I'm using CLion 2018.2 to write C/C++ code for a custom compiler toolchain which are not supported natively by CLion. I currently compile with make on the Terminal instead of building from within the IDE.
I have a custom include directory with header files which are not resolved/found by CLion since they are not part of the project. However, I want to get code inspection features for them. The headers are e.g. located at C:\devkitPro\wups\include.
I decided to use the include_directories() CMake command to improve CLion's ability to resolved code:
include_directories("C:\\devkitPro\\wups\\include")
Then I also modified the CMake include path:
set(CMAKE_INCLUDE_PATH "C:\\devkitPro\\wups\\include")
And also decided to link against the lib directory:
link_directories("C:\\devkitPro\\wups\\lib")
After doing all that, the headers still aren't resolved in CLion (but it still compiles using make of course). How can the header resolution be done with CLion or is it not possible, yet?
Depending on the configured toolchain in CLion, CMake expects a Windows or a WSL-style path. Inspections will work with the include_directories directive, e.g.
# Add extra include directories
if (WIN32) # When using a Windows compilation toolchain
set(WUT "/c/devkitPro/wut/include")
set(WUPS "/c/devkitPro/wups/include")
else () # When using WSL as toolchain
set(WUT "/mnt/c/devkitPro/wut/include")
set(WUPS "/mnt/c/devkitPro/wups/include")
endif ()
include_directories(${WUT})
include_directories(${WUPS})
A more detailed written tutorial can be found in this pull request.
Related
I'm currently learning C++ and I'm working on a small project. I was wondering how I can generate an executable of my project. I'm not sure how to do it, I'm using Ubuntu 20.04
I've googled it but I can not find any instructions on how to do it.
Well. If you are using CLion, you can just create a new project, and check the CMake file that CLion generate. Something like this:
cmake_minimum_required(VERSION 3.20)
project(Test)
set(CMAKE_CXX_STANDARD 14)
add_executable(Test main.cpp)
And in that file there was a line with a function called add_executable, in that function you set first the exe name and then the source files. And just run the project in CLion. By default CLion create a directory calle "cmake-build-debug" where the exe file are located.
If you want to add more libraries, change the binaries source directory and more. You will need learn CMake. Also you can use CMake standalone whiteout CLion, you just need install it sudo apt-get install cmake and use then in the terminal.
Expanding over #Steback's answer:
First, a clarification: an executable file is a file that can be executed by the system. It (roughly) contains assembly commands. Under Windows executable files are marked with an .exe extension. Under linux, they are usually extension-less.
To generate an executable file from C / C++ code you ("only") need a C/C++ compiler. A default / pre-installed one on Ubuntu is gcc / g++ (whereas on Windows you need to actively install one).
CLion is an IDE and (exactly like any other IDE) can run the compiler for you. IDE (stands for Integrated Development Environment) is a program which incorporates (minimally) a text/code editor, a compiler and a debugger (all of which it invokes normally via command line, just as you can do yourself).
CLion is an advanced (and excellent) IDE. In CLion, the way you specify how exactly it should invoke the compiler is via the CMake language (not to be confused with the unix tool make which chiefly only knows to run commands conditionally on file modified date).
CMake code should be placed in a file named CMakeLists.txt in the project root directory (sometimes CLion creates this file for you automatically). A minimal cmake project looks like
# Specify cmake language version to use for this file
cmake_minimum_required(VERSION 3.10)
# Specify any name for the project
project(NameYourProject)
# A name for your executable file and the code files needed to build it
add_executable(YourExecutableName source_file1.cpp somefolder/source_file2.cpp header_file.h)
Of course this is just a very minimal example. The CMake language is a powerful language to specify build processes, with cross-platform support. You can look it up / learn it someday.
When giving the "build" command to CLion it will now do two things:
use the cmake tool to generate a set of commands for gcc/g++ (this is called "cmake configure" + "cmake generate") - according to what you wrote in CMakeLists.txt
run the generated commands to hopefully build your executable.
As a beginner, you may be better off first trying to run the compiler yourself via the command line to see what it does. You can also opt for a different IDE (e.g. CodeBlocks, eclipse, Dev C++) where you specify what you need the compiler to do via a GUI and not via CMake (although CMake is arguably more convenient).
I'm using Dev C++. When I run and compile it, it automaticcally generate a .exe file. Just install it and open ur file with it and compile it. Should work good.
I have a custom build cmake v3.10.0 which was compiled with a gcc_4.8.3. I am using this custom build cmake to compile a cmake project that must use gcc _4.1.2 because of legacy code.
Executing cmake promted me with an error because it needs to use the libstdc++-IFX.so.6 provided by gcc_4.8.3 which I fixed by adding the path to the correct library in my LD_LIBRARY_PATH before the path to the libraries provided by gcc_4.1.2.
Compiling my project and linking an executable (which is done by c++) results in the linker taking the gcc_4.8.3 stdlibs over the gcc_4.1.2 libs. Is there any way to tell cmake to not use the libraries it needs for himself for my cmake project preferably without touching LD_LIBRARY_PATH?
Edits:
#squareskittles comment: I did read and try everything this post suggest but without any changes. The libstdc++-IFX.so.6 is still taken from gcc_4.8.3
When using CMake on unix I dont have any issues. I can use CLion to do a cmake setup, cmake build and cmake install, open a different project and it will find the previously built library when using find_package. On windows this does not seem to be possible. By default it tries to install the build code into strange directories (like C:\Program Files). I have added a CMAKE_INSTALL_PREFIX to both my library CMakeLists.txt and the appliation CMakeLists.txt, however when using find_package(SDL2)CMake still complains there is no config file for CMake and SDL2. When checking the following file exists:
U:\various\cmake-cache\Program Files (x86)\SDL2\cmake\SDL2Config.cmake
The directory U:\various\cmake-cache was used as CMAKE_INSTALL_PREFIX for both SDL2 and my application. Yet it still refuses to compile.
What can I do to make CMake at least somewhat useful on windows? On Unix things work great, but it feels like a huge PITA on Windows so far... It seems like all the concepts dont work there. I would really like to have one central location that is used by every CMake build on my system and everything is installed there and when another project uses a library it is searched there. Is this possible?
I have a project divided in modules, here is a dummy example:
root
CMakeLists.txt
modules
utils
CMakeLists.txt
src
util_file.cpp
cuda
CMakeLists.txt
src
cuda_file.cu
If I edit the cuda_file.cu with CLion, all the symbols are unresolved (even the includes from standard library) by CLion. All the code completion/creation features are then of course gone (among other things). The problem seems to be that whenever you create a library or an executable with only CUDA files, Clion becomes stupid and doesn't parse or resolve anything anymore.
There is two workarounds I've found but they are not friendly or "clean" to use :
add an empty .cpp file to the directory and add it to the add_library() CMake line.
switch to another library or executable target that has .cpp files (like utils in my dummy example). But then when you want to compile or execute you have to switch again to cuda target (or some subtarget like test_cuda for test units) and then switch back again to continue coding or debugging, etc...
Here is the CMakeLists.txt from the cuda module with the workaround:
cmake_minimum_required(VERSION 3.5)
message(STATUS "Configuring module cuda")
# Build module static library
FILE(GLOB CUDA_SRCS
${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp)
FILE(GLOB CUDA_CU_SRCS
${CMAKE_CURRENT_SOURCE_DIR}/src/*.cu)
FILE(GLOB CUDA_CU_HDRS
${CMAKE_CURRENT_SOURCE_DIR}/include/*.cuh)
cuda_compile(cuda_objs ${CUDA_CU_SRCS} ${CUDA_CU_HDRS})
add_library(cuda STATIC ${CUDA_SRCS} ${cuda_objs})
# because only .cu files, help cmake detect C++ language
set_target_properties(cuda PROPERTIES LINKER_LANGUAGE CXX)
Is there a way to avoid CLion derping when resolving links to other headers and libraries ?
I've already added .cu and .cuh files as C/C++ code in CLion options and tried using JETBRAINS_IDE define option as explained in another similar post, but those two problems are not the same.
It seems like without the intervention of Jetbrains to add official CUDA support, the most I could get out of the combo CLion + CMake + CUDA was achieved by:
adding .cu and .cuh as C++ files in CLion. This allows Clion to recognize cuda code as C++ code and color it correctly.
adding an empty dummy .cpp file to the cuda source directory if it is only filled by .cu files (one of my "dirty" hacks from my question). I could not find better. This allows Clion to not completely derp. A simple thing like recognizing cstdio doesn't work without this "hack" and CLion is basically an enhanced notepad.
using when possible CMake 3.8+ that officially supports CUDA as a language and use the new "cuda aware" add_library() instead of the old macro defined cuda_add_library(). This can avoid problems in the future in case of deprecation.
in the CMakeLists of the cuda module (or main CMakeLists if only one), include the path to the include directory of cuda to allow Clion to "see" the cuda headers. CLion can then propose to you to include them so that CLion resolves correctly CUDA API calls like cudaMalloc() or cudaFree(). This is only needed for CLion as the CUDA compiler doesn't need this includes to compile properly (cuda.h, cuda_runtime.h, ...).
use this answer to create a "clion helper" header file, so that it doesn't derp on symbols like __device__ or __global__.
I think that if Jetbrains starts adding support for CUDA, not also will it remove the need to add this dummy file, but it will probably also resolve all other things listed.
Here is the link to the nvidia blog with examples about the official cuda language support in CMake and new "cuda aware" add_library() : https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/
As of the version 2020.1 of CLion, CUDA projects are now officially supported
https://blog.jetbrains.com/clion/2020/04/clion-2020-1-cuda-clang-embedded/
I have been trying to use SFML in a CMake project, specifically the header SFML/Audio.hpp. I installed SMFL using Homebrew, and both the .dylib-files and the headers should be located correctly, in /usr/local/lib and /usr/local/include, respectively.
Now running CMake works fine, telling me that it has Found SFML 2.4.2 in /usr/local/include.
However, when compiling the project (using make), I get the following error:
/path/to/project.hpp:12:10: fatal error: 'SFML/Audio.hpp' file not found.
Does anyone know why this is happening?
Note: Compiling works fine for colleagues of mine using the same CMake- and source files on various Linux operating systems.
This sounds like you simply forgot to add SFML's include directory. On Linux, they probably install SFML to some system path where GCC (or Clang) look by default, so they don't need any additional CMake directives.
Luckily, fixing this is pretty simple.
Add the following line to your CMakeLists.txt somewhere before defining targets:
include_directories(${SFML_INCLUDE_DIR})
The variable SFML_INCLUDE_DIR is populated when you successfully call find_package(SFML...).
While you're at it, you might also want to ensure to link to the proper library files in the correct order:
target_link_libraries(myTargetName ${SFML_LIBRARIES} ${SFML_DEPENDENCIES})
Again, both variables are populated automatically.