Hooking up CLion with Qt - c++

I want to be able to run my Qt applications from CLion. In order to do so, I'm using MinGW, CLion, and Qt 5.15.0. In Settings > Build, Execution, Deployment > CMake, I've set my CMake Options as the following:
-DCMAKE_PREFIX_PATH=/Qt/5.15.0/mingw81_64/lib/cmake
In Settings > Build, Execution, Deployment > Toolchains, I've set my Environment as the following:
C:\Qt\Tools\mingw810_64
The C and C++ compilers have been automatically detected so I'm not too worried about that. For the file main.cpp, I have the following:
#include <QApplication>
#include <QDebug>
int main() {
qDebug() << QT_VERSION_STR;
return 0;
}
For CMakeLists.txt, I have the following:
cmake_minimum_required(VERSION 3.3)
project(Practice)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES main.cpp)
find_package(Qt5Widgets REQUIRED)
add_executable(Practice ${SOURCE_FILES})
target_link_libraries(Practice Qt5::Widgets)
Building this test project gives me no warnings or errors but running it does. Why is this? Here's the error code I get when it does run.
C:\Users\IvanJaramillo\CLionProjects\Practice\cmake-build-debug\Practice.exe
Process finished with exit code -1073741511 (0xC0000139)
Changing compilers from MinGW to Cygwin and changing the versions of it hasn't done the job.

Related

CLion IDE (CMake): Project builds but no intelligence for external libraries

I've implemented the GLFW basic example.
The GLFW header file is reported as not being found and such the CLion IDE is reporting and error and not providing intellisense however the project correctly compiles and runs.
I've added the GLFW library as per the guidance in their documentation (See CMakeLists.txt).
The project is being built and run remotely on Ubuntu 20.04.
main.cpp
#include <GLFW/glfw3.h>
int main(void)
{
GLFWwindow* window;
/* Initialize the library */
if (!glfwInit())
return -1;
...
}
CMakeLists.txt
project(untitled1)
set(CMAKE_CXX_STANDARD 14)
set(SOURCE_FILES main.cpp)
find_package(glfw3 3.3 REQUIRED)
add_executable(untitled1 ${SOURCE_FILES})
target_link_libraries(untitled1 glfw)
For anyone encountering this issue call Tools | Resync with Remote Hosts -

Index Qt5 in Eclipse IDE project using Cmake

Background
I'm currently using Eclipse Neon.3 and have installed the "C/C++ CMake Build Support - Experimental" package (I'm not using CMake's Eclipse generator). I have a simple program that uses Qt 5.8 which builds successfully, however, Eclipse seems unable to index Qt symbols(e.g. QCoreApplication, QDebug, etc...).
The symptoms of this are:
No code completion suggestions
#include <QtCore> and other include statements are shown as unresolved
Qt symbols such as QCoreApplication, QDebug(), and QCoreApplication.exec() are shown as not resolved.
Code
CMakeLists.txt file
cmake_minimum_required(VERSION 3.5)
project(test-program)
set(CMAKE_CXX_STANDARD 11)
# Put the CMake files for Qt5 in the Prefix path.
set(Qt5_DIR /opt/Qt/5.8/gcc_64/lib/cmake/Qt5/)
#Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
#Instruct CMake to run moc automatically when needed.
set(CMAKE_AUTOMOC ON)
#Find the Qt5Core Library
find_package(Qt5 REQUIRED COMPONENTS Core Widgets)
set(SOURCE_FILES
src/main.cpp)
add_executable(${PROJECT_NAME} ${SOURCE_FILES})
target_link_libraries(${PROJECT_NAME} Qt5::Core)
main.cpp (shown with eclipse annotations)
#include <QtCore> //Unresolved inclusion: <QtCore>
#include <QDebug> //Unresolved inclusion: <QDebug>
int main(int argc, char** argv){
QCoreApplication application(argc, argv);
//Type 'QCoreApplication' could not be resolved
qDebug() << "Test";
//Function 'qDebug' could not be resolved
application.exec();
//Method 'exec' could not be resolved
return 0;
}
Question
So my question is this: How can I get Eclipse to recognize Eclipse to recognize Qt symbols? Or is that just not possible at this time?
Did you enable the "CDT GCC Build Output Parser"? This is an Eclipse feature to parse the output of the build and guesses the include paths automatically. You can find it unter Project Properties->C/C++ General->Preprocessor Include Paths, Macros etc. and then under the tab Providers.
In order for this feature to work properly, a detailed build report must be generated. You can achieve this by either changing the build command under Preferences->C/C++ Build to make VERBOSE=1 or by specifying set(CMAKE_VERBOSE_MAKEFILE On) inside your CMakeLists.txt.
See also Eclipse Help - Scanner Discovery Preferences

Setting up Qt for CLion

i am struggling to set up Qt5 for CLion. Somehow, I did this for VS before but failed to do this in CLion. Building and Including Qt headers are fine and CLion find qt symbols and auto-completes them but when i am using an Qt object Clion giving me this error:
C:\Users\binhb.CLion2016.1\system\cmake\generated\LBMTopoOptimization-ae159e87\ae159e87\Debug\LBMTopoOptimization.exe
Process finished with exit code -1073741515 (0xC0000135)
My CMake file looks like this:
cmake_minimum_required(VERSION 3.5)
project(LBMTopoOptimization)
# Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Instruct CMake to run moc automatically when needed.
set(CMAKE_AUTOMOC ON)
# set prefix path for Qt5
set (CMAKE_PREFIX_PATH "C:\\QT\\5.7\\mingw53_32\\")
# Find QT Libraries
find_package( Qt5Core REQUIRED )
find_package( Qt5Widgets REQUIRED )
find_package( Qt5Gui REQUIRED )
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -std=c++11")
set(SOURCE_FILES main.cpp)
add_executable(LBMTopoOptimization ${SOURCE_FILES})
# Use the modules from Qt 5.
target_link_libraries(LBMTopoOptimization Qt5::Widgets Qt5::Core Qt5::Gui)
The error would already occur by using for example a QString:
#include <QWidget>
int main(int argc, char** argv ){
QString name = "this is a string";
return 0;
}
System specification:
Windows 10
Clion 1.3
Qt 5.7
CMake 3.6 rc3
mingw-gcc 4.9.3
I looking forward for any hints.
Try to add Qt library's installation directory (select specific Qt version and build system \bin sub-subdirectory) to PATH environment variable .
I have been struggling with similar problem. I have had installed Qt library (version 5.6 and 5.7) in C:\Qt\ directory. In my project I use version 5.6. Build system is MinGW.
After I have added C:\Qt\5.6\mingw49_32\bin, everything works fine.
The reason for this behaviour is quite simple. During the build, build system 'knows' where to search for libraries, but when app is being executed, Windows system searches for required libraries in application's directory and directories specified by PATH variable.
If it fails, application exits with -1073741515 (0xC0000135) error.

SFML not found - CLion/Cmake

I'm basically trying to make an SFML project in CLion which uses CMake.
I first downloaded SFML 2.2 which already had the .dylib files built. It said to install them in usr/local/lib and usr/local/include, but they didn't exist, so I created them and then put the files there.
I then opened up CLion, created a subdirectoy cmake_modules, placed the FindSFML.cmake file inside, and in the root project directory placed these files:
main.cpp
#include <SFML/Graphics.hpp>
int main()
{
sf::err() << "Hello, World!" << std::endl;
return 0;
}
CMakeLists.txt:
cmake_minimum_required(VERSION 3.2)
project(HelloWorld)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES main.cpp)
add_executable(HelloWorld ${SOURCE_FILES})
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})
find_package(SFML COMPONENTS graphics window system REQUIRED)
include_directories(${SFML_INCLUDE_DIR})
target_link_libraries(HelloWorld ${SFML_Libraries})
The problem is that when I try to build the project, I get the following error:
Undefined symbols for architecture x86_64:
"sf::err()", referenced from:
_main in main.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've tried searching for a solution, but none of them seem to be working. Did I put the files in the wrong place, or did I forget some import CMake setting? I know that setting SFML up with Xcode would be easier, but I'd prefer to use CLion if at all possible.
Ok, so I made an entirely new project, ran xcode-select --install on my terminal to make /usr/local/ a directory that gets searched by the compiler, downloaded SFML 2.3 instead of 2.2, decided to use the FindSFML.cmake file shipped with SFML, and made my CmakeLists.txt file look like so:
cmake_minimum_required(VERSION 3.2)
project(SFMLTest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES main.cpp)
add_executable(SFMLTest ${SOURCE_FILES})
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "~/SFML-2.3/cmake/Modules/")
find_package(SFML REQUIRED graphics window system)
if (SFML_FOUND)
include_directories(${SFML_INCLUDE_DIR})
target_link_libraries(SFMLTest ${SFML_LIBRARIES})
endif(SFML_FOUND)
This compiled and ran the following code in CLion:
#include <iostream>
#include <SFML/Graphics.hpp>
using namespace std;
int main()
{
sf::RenderWindow window(sf::VideoMode(640, 480), "Window");
while (window.isOpen())
{
sf::Event e;
while (window.pollEvent(e))
{
if (e.type == sf::Event::Closed)
{
window.close();
}
}
window.clear();
window.display();
}
return 0;
}
I don't know what exactly fixed everything, but I'm just glad it did. Hopefully this helps anyone else who's in a similar jam.
For SFML 2.5 and greater a more modern approach has been taken and setting up cmake is easier.
Example CMakeLists.txt
cmake_minimum_required(VERSION 3.1)
project(SFMLTest)
find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest sfml-graphics sfml-audio)
Note :
Its no longer needed to setup FindSFML.cmake or SFML_ROOT etc.
SFML_LIBRARIES, SFML_DEPENDENCIES and SFML_INCLUDE_DIR don't exist
anymore
More info https://en.sfml-dev.org/forums/index.php?topic=24070.0
For others who downloaded SFML via brew, I managed to fix this by adding this to my CMakeLists.txt
set(SFML_ROOT /usr/local/lib)

Bus error 10 / Library not loaded error with PCL and cmake

I'm using the point cloud library and tried to downsample a point cloud using a voxel grid. It worked fine when I was using Xcode, where I manually added the required libraries, but not with cmake. The program compiles fine with cmake but if I run the program compiled by cmake I get the following error:
$ ./main
$ Bus error: 10
I figured out that the error only occurs when pcl/filters/voxel_grid.h is included. I used other classes of PCL in the program before and everything worked fine with cmake.
If also figured out that if pcl/filters/voxel_grid.h is included and I remove set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") from my cmake file the program will compile and run fine just like it did in Xcode(language dialect in Xcode is set to C++11). The problem is, I need c++11 features and also cmake since I need to be able to easily build the program on a different OS.
I'm on OS X 10.9.2 and using clang 3.4, boost 1.55.0, PCL 1.7.1 and CUDA 5.5.
It would be great if someone could help me.
Thanks for your help
Here is a minimal example:
//main.cpp
#include <pcl/filters/voxel_grid.h> // it works if this include is removed
int main(int argc, const char * argv[])
{
return 0;
}
The cmake file I use:
#cmake file
cmake_minimum_required(VERSION 2.6 FATAL_ERROR)
project(test)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
find_package(PCL 1.7 REQUIRED)
find_package(Boost 1.55 REQUIRED)
include_directories(${PCL_INCLUDE_DIRS} ${BOOST_INCLUDE_DIRS})
add_executable(main main.cpp)
target_link_libraries(main ${PCL_LIBRARIES} ${BOOST_LIBRARIES})
Solution/Error cause
I found the root cause of the problem. I compiled an example what causes the same problem manually on the console so that I could compare the different compiler flags/settings used by Xcode and cmake.
What I found out is, that Xcode adds some flags that cmake doesn't add. One of the flags/options Xcode adds is "-fvisibility-inlines-hidden". With that option set the example program compiles and runs fine, without the option set it compiles but generates a "Bus error: 10" at runtime.
It would be great if some could explain what that option does and why it's necessary when compiling. Is this just clang or OS X specific, so that on a different OS/compiler the option isn't needed?
Regards and thanks,
Ruediger