I'm trying to use CLion to create a SDL2 project.
The problem is that the SDL headers can't be found when using #include's.
My CMakeLists.txt file:
cmake_minimum_required(VERSION 2.8.4)
project(ChickenShooter)
set(SDL2_INCLUDE_DIR C:/SDL/SDL2-2.0.3/include)
set(SDL2_LIBRARY C:/SDL/SDL2-2.0.3/lib/x64)
include_directories(${SDL2_INCLUDE_DIR})
set(SOURCE_FILES main.cpp)
add_executable(ChickenShooter ${SOURCE_FILES})
target_link_libraries(ChickenShooter ${SDL2_LIBRARY})
My test main.cpp:
#include <iostream>
#include "SDL.h" /* This one can't be found */
int main(){
if (SDL_Init(SDL_INIT_VIDEO) != 0){
std::cout << "SDL_Init Error: " << SDL_GetError() << std::endl;
return 1;
}
SDL_Quit();
return 0;
}
Thank you for any help you could give me.
Edit:
I'm using Windows and CLion is configured to use cygwin64.
This blog post shows how you can do it: Using SDL2 with CMake
On Linux you can use a recent CMake (e.g. version 3.7) and using SDL2 works out of the box.
cmake_minimum_required(VERSION 3.7)
project(SDL2Test)
find_package(SDL2 REQUIRED)
include_directories(SDL2Test ${SDL2_INCLUDE_DIRS})
add_executable(SDL2Test Main.cpp)
target_link_libraries(SDL2Test ${SDL2_LIBRARIES})
Under Windows you can download the SDL2 development package, extract it somewhere and then create a sdl-config.cmake file in the extracted location with the following content:
set(SDL2_INCLUDE_DIRS "${CMAKE_CURRENT_LIST_DIR}/include")
# Support both 32 and 64 bit builds
if (${CMAKE_SIZEOF_VOID_P} MATCHES 8)
set(SDL2_LIBRARIES "${CMAKE_CURRENT_LIST_DIR}/lib/x64/SDL2.lib;${CMAKE_CURRENT_LIST_DIR}/lib/x64/SDL2main.lib")
else ()
set(SDL2_LIBRARIES "${CMAKE_CURRENT_LIST_DIR}/lib/x86/SDL2.lib;${CMAKE_CURRENT_LIST_DIR}/lib/x86/SDL2main.lib")
endif ()
string(STRIP "${SDL2_LIBRARIES}" SDL2_LIBRARIES)
When you now configure inside the CMake-GUI application there will be a SDL2_DIR variable. You have to point it to the SDL2 directory where you extracted the dev package and reconfigure then everything should work.
You can then include SDL2 headers by just writing #include "SDL.h".
Don't set the path to SDL2 by hand. Use the proper find command which uses FindSDL. Should look like:
find_file(SDL2_INCLUDE_DIR NAME SDL.h HINTS SDL2)
find_library(SDL2_LIBRARY NAME SDL2)
add_executable(ChickenShooter main.cpp)
target_include_directories(ChickenShooter ${SDL2_INCLUDE_DIR})
target_link_libraries(ChickenShooter ${SDL2_LIBRARY})
If SDL2 is not found, you have to add the path to SDL2 to CMAKE_PREFIX_PATH, that's the place where CMake looks for installed software.
If you can use Pkg-config, its use might be easier, see How to use SDL2 and SDL_image with cmake
If you feel more comfortable to use a FindSDL2.cmake file similar to FindSDL.cmake provided by CMake, see https://brendanwhitfield.wordpress.com/2015/02/26/using-cmake-with-sdl2/
You can also pull in the SDL source repository as a submodule and build/link it statically along with your main program via add_subdirectory() and target_link_libraries():
cmake_minimum_required( VERSION 3.18.0 )
project( sdl2-demo )
set( SDL_STATIC ON CACHE BOOL "" FORCE )
set( SDL_SHARED OFF CACHE BOOL "" FORCE )
# 'external/sdl' should point at a SDL
# repo clone or extracted release tarball
add_subdirectory( external/sdl )
add_executable(
${CMAKE_PROJECT_NAME}
"src/main.cpp"
)
target_link_libraries( ${CMAKE_PROJECT_NAME} SDL2main SDL2-static )
(At least as of the release-2.0.9 tag, possibly earlier.)
I recently discovered the latest version of SDL2 (version 2.0.12) now comes with all the required CMake config/install scripts, so there's no need to use FindSDL anymore.
I downloaded the SDL source from https://www.libsdl.org/download-2.0.php then from the root folder ran...
cmake -S . -B build/debug -G Ninja -DCMAKE_INSTALL_PREFIX=./install -DCMAKE_BUILD_TYPE=Debug
cmake --build build/debug --target install
This will build and install the debug version of the library, you can then also run...
cmake -S . -B build/release -G Ninja -DCMAKE_INSTALL_PREFIX=./install -DCMAKE_BUILD_TYPE=Release
cmake --build build/release --target install
Which will build and install the release version of the library (and because the SDL CMake script uses DEBUG_POSTFIX the release version of the library won't overwrite the debug one as the debug versions all have 'd' appended to their name).
In your CMakeLists.txt file you can then simply do this:
find_package(SDL2 REQUIRED)
add_executable(${PROJECT_NAME} ...)
target_link_libraries(
${PROJECT_NAME} PRIVATE
SDL2::SDL2
SDL2::SDL2main
You'll need to tell your application where to find the SDL install folder if you used a custom location as I've done in the example. To do this from the root folder of your app run:
cmake -S . -B build/debug -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_PREFIX_PATH=</absolute/path/to/install/dir>
cmake --build build/debug
Note: You can use $(pwd) (*nix/macOS) or %cd% (Windows) to create a hybrid relative path which can be very useful.
You can omit both DCMAKE_INSTALL_PREFIX and DCMAKE_PREFIX_PATH if you want to install SDL to the default system location.
In the examples I've opted to use the Ninja generator as it is consistent across macOS/Windows - it can be used with MSVC/Visual Studio, just make sure you run this (path may differ slightly depending on year/version) to add Ninja to your path.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat
Update:
One other thing I remembered which is useful on Windows is the ability to copy the SDL .dll file into the application binary directory, this can be achieved like so:
if (WIN32)
# copy the .dll file to the same folder as the executable
add_custom_command(
TARGET ${PROJECT_NAME} POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
$<TARGET_FILE:SDL2::SDL2>
$<TARGET_FILE_DIR:${PROJECT_NAME}>
VERBATIM)
endif()
Using the SDL2 CMake module that I developed, you can integrate the SDL2 library easily in a modern and portable approach.
You should just copy the module in cmake/sdl2 (Or just clone the modules repo) in your project:
git clone https://github.com/aminosbh/sdl2-cmake-modules cmake/sdl2
Then add the following lines in your CMakeLists.txt:
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake/sdl2)
find_package(SDL2 REQUIRED)
target_link_libraries(${PROJECT_NAME} SDL2::Main)
Note: If CMake didn't find the SDL2 library (in Windows), we can specify the CMake option SDL2_PATH as follows:
cmake .. -DSDL2_PATH="/path/to/sdl2"
For more details, please read the README.md file.
The SDL2 CMake modules support other related libraries : SDL2_image, SDL2_ttf, SDL2_mixer, SDL2_net and SDL2_gfx.
You can find a list of examples/samples and projects that uses these modules here : https://github.com/aminosbh/sdl-samples-and-projects
With the compiled version of SDL2-2.0.9 with MinGW-w64 in Windows, the following configuration works for me:
find_package(SDL2 REQUIRED)
add_executable(sdl-test ${SOURCES})
target_link_libraries(sdl-test
mingw32
SDL2::SDL2main
SDL2::SDL2
)
A longer explanation
By reading SDL2Targets.cmake file, I've learned that SDL2 is providing several targets:
SDL2::SDL2main (lib/libSDL2main.a)
SDL2::SDL2 (lib/libSDL2.dll.a)
SDL2::SDL2-static (lib/libSDL2-static.a)
Each of them has INTERFACE_INCLUDE_DIRECTORIES defined, which means we don't need to manually specify include_directories for SDL2.
But by only adding SDL2::SDL2main and SDL2::SDL2 as target_link_libraries is not enough. The g++ compiler might be complaining about "undefined reference to `WinMain'".
By inspecting the compiler options, I found that the SDL2 libraries are added before -lmingw32 option. In order to make the -lmingw32 option comes before SDL2 libraries, we have to also specify mingw32 as the first target_link_libraries. Which will make this configuration working.
The command that I have used for building it is:
$ mkdir build && cd build && cmake .. -G"MinGW Makefiles" && cmake --build .
The only small problem here is in the finally generated compiler options, the -lmingw32 option is duplicated. But since it doesn't affect the linking process, I've ignored it for now.
On Linux, in Clion, this works:
cmake_minimum_required(VERSION 3.20)
project(first_game)
set(CMAKE_CXX_STANDARD 14)
find_package(SDL2 REQUIRED)
include_directories(${SDL2_INCLUDE_DIRS})
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} ${SDL2_LIBRARIES})
You don't seems to have a CMake error whike generating your make file. But I think your problem is, the SDL Header are located in a subfolder named "SDL2".
Change your CMakeLists.txt to include
C:/SDL/SDL2-2.0.3/include/SDL2
Instead of
C:/SDL/SDL2-2.0.3/include
I had the same problem and none of the other solutions worked.
But I finally got it working by following this solution : How to properly link libraries with cmake?
In a nutshell, the problem was that the SDL2 library was not linked properly in my CMakeLists.txt. And by writing this into the file, it worked (more explainations in the other thread) :
project (MyProgramExecBlaBla) #not sure whether this should be the same name of the executable, but I always see that "convention"
cmake_minimum_required(VERSION 2.8)
ADD_LIBRARY(LibsModule
file1.cpp
file2.cpp
)
target_link_libraries(LibsModule -lpthread)
target_link_libraries(LibsModule liblapack.a)
target_link_libraries(LibsModule -L/home/user/libs/somelibpath/)
ADD_EXECUTABLE(MyProgramExecBlaBla main.cpp)
target_link_libraries(MyProgramExecBlaBla LibsModule)
Highlighting the steps of how I was able to eventually accomplish this using the FindSDL2.cmake module:
Download SDL2-devel-2.0.9-VC.zip (or whatever version is out after this answer is posted) under the Development Libraries section of the downloads page.
Extract the zip folder and you should see a folder similar to "SDL2-2.0.9". Paste this folder in your C:\Program Files(x86)\ directory.
Copy the FindSDL2.cmake module and place it in a new "cmake" directory within your project. I found a FindSDL2.cmake file in the answer referenced in the Accepted Answer: https://brendanwhitfield.wordpress.com/2015/02/26/using-cmake-with-sdl2/
Find the SET(SDL2_SEARCH_PATHS line in the FindSDL2.cmake and add your copied development directory for SDL2 as a new line: "/Program Files (x86)/SDL2-2.0.9" # Windows
Within my CMakeLists.txt, add this line: set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)
After this, running CMake worked for me. I'm including the rest of my CMakeLists just in case it further clarifies anything I may have left out:
cmake_minimum_required(VERSION 2.8.4)
project(Test_Project)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
# includes cmake/FindSDL2.cmake
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)
set(SOURCE_FILES src/main.cpp src/test.cpp)
add_executable(test ${SOURCE_FILES})
# The two lines below have been removed to run on my Windows machine
#INCLUDE(FindPkgConfig)
#PKG_SEARCH_MODULE(SDL2 REQUIRED sdl2)
find_package(SDL2 REQUIRED)
INCLUDE_DIRECTORIES(${SDL2_INCLUDE_DIR})
TARGET_LINK_LIBRARIES(chip8 ${SDL2_LIBRARY})
Hope this helps somebody in the near future.
by the time of my answer, SDL2 is provided with sdl2-config executable (as I understand, developers call him "experimental").
After "make install" of SDL2 you can try calling it from terminal with
sdl2-config --cflags --libs to see what it outputs.
And then you can add call to it in your makefile:
set(PROJECT_NAME SomeProject)
project(${PROJECT_NAME})
execute_process(COMMAND /usr/local/bin/sdl2-config --libs RESULT_VARIABLE CMD_RES OUTPUT_VARIABLE SDL2_CFLAGS_LIBS ERROR_VARIABLE ERR_VAR OUTPUT_STRIP_TRAILING_WHITESPACE)
message("SDL2_CFLAGS_LIBS=${SDL2_CFLAGS_LIBS}; CMD_RES=${CMD_RES}; ERR_VAR=${ERR_VAR}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 ${SDL2_CFLAGS_LIBS}")
set(SOURCE_FILES main.cpp)
add_executable(${PROJECT_NAME} ${SOURCE_FILES})
Here I have a problem - if I only put an executable name without path like
execute_process(COMMAND sdl2-config --libs <...>
I get error "No such file", i.e. cmake does not search in current path and I don't know how to write it properly by now.
One more notice: in my makefile I do not user --cflags option, because cmake finds includes correctly and I do not need to specify them explicitly.
For your information, I was able to successfully cmake and compile SDL2_ttf while linking to SDL2 source code.
At first I was getting errors due to cmake not being able to locate SDL2, even though it was specified in cmake using the SLD2_DIR variable in cmake.
It seems that for some reason cmaking SDL2 fails to create the SDL2Targets.cmake file which is searched for by SDL2_ttf
If this is the case for you, get the SDL2Targets.cmake file from https://bugs.archlinux.org/task/57972 and modify the file like so:
You can remove the following lines:
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
set(_IMPORT_PREFIX "")
endif()
and add this one:
set(_IMPORT_PREFIX "C:/SDL2-2.0.12")
Obviously change the filepath to the place you unpacked the SDL2 source code
I'm not sure if this is exactly your issue, but there it is.
I'm trying to build a with Qt 5.14 an application on release mode and everything is working fine inside of Qt Creator, but when I'm trying to run the executable by itself I'm getting an error like this:
OS: Windows 10
Qt: 5.14
Cmake: 3.5
What I've tried:
set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -fPIC")
${ADDITIONAL_LIBRARIES} -static inside of target_link_libraries
None of the above worked for me and I'm getting the same error whenever I'm trying to run the executable by its self without using Qt Creator.
My CMake file:
cmake_minimum_required(VERSION 3.5)
project(Scrollable LANGUAGES CXX)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -fPIC")
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
find_package(Qt5 REQUIRED Core Widgets Gui Qml Quick Qml)
qt5_add_resources(resource.qrc)
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
include_directories("MoviesInterface")
set(SOURCES
main.cpp
MovieInterface/movieinterfaceomdb.cpp
MovieInterface/moviesinterface.cpp
)
set(HEADERS
MovieInterface/movieinterfaceomdb.h
MovieInterface/moviesinterface.h
)
add_executable(Scrollable ${SOURCES} ${HEADERS} qml.qrc)
qt5_use_modules(Scrollable Core Network)
target_link_libraries(Scrollable
Qt5::Core
Qt5::Gui
Qt5::Widgets
Qt5::Qml
${ADDITIONAL_LIBRARIES} -static
)
A You want to statically compile. This won't work for Qt libs and Mingw libs itself, because these would need to be compiled statically, too.
But they are only distributed as dynamic linked libraries.
If you really want to have statically linkable Qt libs, you would need to compile Qt statically, before you can link them. There are some descriptions for compiling Qt statically out there. But it's a lot of work.
B Why Qt5Core.dll is not found:
Inside Qt Creator the path to the Qt libraries for your application is automatically set, because of Compiler/Toolchain auto-detection.
But, when you run your application executable standalone, the path to the Qt libs is not set and they do not reside in the application folder next to the executable.
To solve this i would suggest using windeployqt.
windeployqt analyzes the library or executable you build and copies the needed Qt dependencies into the build folder.
I tend to use a cmake helper function for this.
Create windeployqt.cmake with the following content and place it into /cmake modules folder of your project:
find_package(Qt5Core REQUIRED)
# get absolute path to qmake, then use it to find windeployqt executable
get_target_property(_qmake_executable Qt5::qmake IMPORTED_LOCATION)
get_filename_component(_qt_bin_dir "${_qmake_executable}" DIRECTORY)
function(windeployqt target)
# POST_BUILD step
# - after build, we have a bin/lib for analyzing qt dependencies
# - we run windeployqt on target and deploy Qt libs
add_custom_command(TARGET ${target} POST_BUILD
COMMAND "${_qt_bin_dir}/windeployqt.exe"
--verbose 1
--release
--no-svg
--no-angle
--no-opengl
--no-opengl-sw
--no-compiler-runtime
--no-system-d3d-compiler
\"$<TARGET_FILE:${target}>\"
COMMENT "Deploying Qt libraries using windeployqt for compilation target '${target}' ..."
)
endfunction()
Note 1: --verbose 1 is set, so that you see what's going on. You might disable it later.
Note 2: Please handle the excludes yourself. I don't know the specific requirements of your app, e.g. if you need OpenGL or SVG support.
Then add to your CMakeLists.txt:
# Set path to our custom CMAKE scripts
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${PROJECT_SOURCE_DIR}/cmake")
# Include Qt deployment helper function
include(windeployqt)
Finally, add to the end of CMakeLists.txt:
windeployqt(Scrollable)
Now, windeployqt is run as a POST_BUILD step on your executable, copying the qt libraries to the build folder. The executable will now pick up the Qt dependencies from this folder and should be able to run standalone (without path to Qt libs set).
Keep in mind to also copy other dependencies, e.g. third-party libs or runtime-dependencies.
Follow-up for your mingw dependencies:
set(QT_MINGW "/path/to/your/qt/mingw/compiler")
add_custom_command(TARGET Scrollable POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QT_MINGW}/bin/libgcc_s_dw2-1.dll $<TARGET_FILE_DIR:${TARGET}>
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QT_MINGW}/bin/libstdc++-6.dll $<TARGET_FILE_DIR:${TARGET}>
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${QT_MINGW}/bin/libwinpthread-1.dll $<TARGET_FILE_DIR:${TARGET}>
COMMENT "Deploy mingw runtime libraries from ${QT_MINGW}/bin"
)
Follow-up for your mingw dependencies:
...
If Qt is installed with MinGW as well, you can avoid additional copy operattions for runtime libraries within add_custom_command just using windeployqt.exe with --compiler-runtime command line option.
I have a folder structure with the following
mainfolder/
folderA/a.dll
folderB/subFolderB/subsubFolderB/b.dll
folderC/c.dll
I want to get all DLLs which are in mainfolder, including sub folders.
I don't get any result by doing a GLOB_RECURSE on the mainfolder. The DLLs are definitely there before the code reaches the GLOB_RECURSE call.
Here is what I am doing:
set(THIRDPARTY_INSTALLFOLDER ${CMAKE_BINARY_DIR}/3rdparty/${CMAKE_BUILD_TYPE})
file(GLOB_RECURSE THEDLLS ${THIRDPARTY_INSTALLFOLDER} "*.dll")
message(STATUS ${THEDLLS})
so the ${THIRDPARTY_INSTALLFOLDER} is the mainfolder I mentioned above. The output of the message with ${THEDLLS} is just nothing.
NOTE: After clean/rebuild/run cmake again it finds the DLLs which are in folderA but nothing more(nothing in folderB or folderC). And again, the DLLs are definitely created before the GLOB_RECURSE call but NOT before the CMakeLists.txt is called.
EDIT: Here is a working example. Be aware that it downloads the rather large library OpenCV. I used this because my main concern is that the DLLs are created in different folder structures depending on which system you built it, which is why copying the DLLs seems so difficult to me. To run this example, just create a CMakeLists.txt and a main.cpp with the following content:
CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(DownloadAndLinkOpenCV)
###First I define where to output .exe and DLLs if there were any
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/build/${CMAKE_BUILD_TYPE}/bin)
###This defines the INSTALL dir of OpenCV(Where to put DLLs etc.)
set(THIRDPARTY_INSTALLFOLDER ${CMAKE_BINARY_DIR}/3rdparty/${CMAKE_BUILD_TYPE})
####function to download and build external project from https://stackoverflow.com/questions/17446981/cmake-externalproject-add-and-findpackage
function (build_external_project target git_repo git_tag cmake_custom_args)
message(STATUS "building ${target} this might take a while...")
set(trigger_build_dir ${CMAKE_BINARY_DIR}/3rdparty_${target})
file(MAKE_DIRECTORY ${trigger_build_dir} ${trigger_build_dir}/build)
set(CMAKE_LIST_CONTENT "
cmake_minimum_required(VERSION 3.13)
include(ExternalProject)
ExternalProject_Add(${target}
GIT_REPOSITORY ${git_repo}
GIT_TAG ${git_tag}
PREFIX ${target}
CMAKE_ARGS ${cmake_custom_args}
)
ExternalProject_Add_StepTargets(${target} build install)
add_custom_target(trigger_${target})
add_dependencies(trigger_${target} ${target})
")
file(WRITE ${trigger_build_dir}/CMakeLists.txt "${CMAKE_LIST_CONTENT}")
execute_process(COMMAND ${CMAKE_COMMAND} .. -G${CMAKE_GENERATOR}
WORKING_DIRECTORY ${trigger_build_dir}/build
)
execute_process(COMMAND ${CMAKE_COMMAND} --build .
WORKING_DIRECTORY ${trigger_build_dir}/build
)
message(STATUS "finished building ${target}!")
endfunction()
####build OpenCV
set(OPENCV_GIT_REPO https://github.com/opencv/opencv.git)
set(OPENCV_TAG 3.4.6)
set(OPENCV_CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX=${THIRDPARTY_INSTALLFOLDER} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}")
build_external_project(opencv ${OPENCV_GIT_REPO} ${OPENCV_TAG} ${OPENCV_CMAKE_ARGS})
####finished building OpenCV now that it is built we can use find_package
set(OpenCV_DIR ${THIRDPARTY_INSTALLFOLDER})
find_package(OpenCV REQUIRED)
####finished 3rdparty building
add_executable(TestApplication main.cpp)
target_link_libraries(TestApplication ${OpenCV_LIBS})
####Now I want to copy the DLLs which were built but GLOB_RECURSE will not give me the name of all DLLs
####I specifically used OpenCV since the main problem is that it creates a more complex folder structure
####in the INSTALL dir. In my case it creates /x64/vc15/...the dlls (x64 is architecture and vc15 the compiler)
####I don't want to hard code the x64/vc15 string because anyone should be able to built it with any compiler
file(GLOB_RECURSE THEDLLS ${THIRDPARTY_INSTALLFOLDER} "*.dll")
message(STATUS ${THEDLLS})
main.cpp
#include <iostream>
#include <opencv2/core.hpp>
int main()
{
cv::Mat Mat;
std::cout<<"Hello World"<<std::endl;
}
Note that I use Qt Creator as IDE and the Visual Studio 2017 compiler
After some additional thoughts I found the very simple solution to it. I did a wrong call to GLOB_RECURSE. Here is the snippet which is working and does what I want: Copying all DLLs inside a folder to a specific directory
####get all dlls in a folder including sub folders
####The wrong call was this one:
####file(GLOB_RECURSE THEDLLS ${THIRDPARTY_INSTALLFOLDER} "*.dll")
file(GLOB_RECURSE THEDLLS "${THIRDPARTY_INSTALLFOLDER}/*.dll")
#####This will copy the DLLs to a folder
foreach(currentDLL ${THEDLLS})
add_custom_command(TARGET TestApplication POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy
${currentDLL}
${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
endforeach(currentDLL)
The thing is GLOB_RECURSE does a complete path pattern matching.
I have the following simple CMake project. It's basically an executable which links dynamically to Qt Widgets (I'm using Qt just as an example). What I'm trying to figure out is whether it is possible to copy all the linked libraries (not only the ones built by the current project) to the executable output directory using CMake.
cmake_minimum_required(VERSION 3.12)
project(MyProject)
set(CMAKE_CXX_STANDARD 14)
set(QT_CMAKE_DIR "/Users/huser/Qt/5.11.1/clang_64/lib/cmake")
set(CMAKE_PREFIX_PATH ${CMAKE_MODULE_PATH} ${QT_CMAKE_DIR})
find_package(Qt5 REQUIRED COMPONENTS Widgets)
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} PUBLIC Qt5::Widgets)
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_LIST_DIR}/build)
The issue is that the output directory only contains the MyProject executable (which is the expected behaviour). However, if I were to distribute that executable to someone who doesn't have Qt installed, they would not be able to open it. Hence, I would like to bundle only the necessary libraries/ frameworks with the executable.
Running otool -L MyProject lists the dependencies:
MyProject:
#rpath/QtWidgets.framework/Versions/5/QtWidgets
#rpath/QtGui.framework/Versions/5/QtGui
#rpath/QtCore.framework/Versions/5/QtCore
/usr/lib/libc++.1.dylib
/usr/lib/libSystem.B.dylib
What I'm looking for is a common way through CMake to get these 3 frameworks copied in the output directory right after the build step. That would result in the following directory structure:
build/
MyProject
QtWidgets.framework
QtGui.framework
QtCore.framework
Any help would be greatly appreciated!
There are two aspects to consider:
the build tree
the install tree
The build tree is what you work with as a developer, the install tree is what is "created" after executing the install target or after extracting the content of a package.
To redistribute your Qt5 based project, I suggest you leverage two tools:
CPack: This allow to create generate packages or archives that can be distributed to users. These includes windows installers, .tar,gz, .dmg, ...
macdeployqt: Tools provided by Qt allowing to copy all libraries, plugins, ... required by your application.
Using the BundleUtilities would still require you to explicitly identify and install all Qt plugins. For more complex application, with dependencies other than Qt, is is indeed helpful but for a simple application, I would suggest to use the approach described below.
You will find below a modified version of your example including some suggestions regarding the best practices as well as the integration of CPack and macdeployqt.
After configuring and building project, building the Package target will create a MyProject-0.1.1-Darwin.dmg package.
Note that more would need to be done but that should give a good starting point.
Reading the following may also be helpful: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
To configure the project, consider passing the variable -DQt5_DIR:PATH=/path/to/lib/cmake/Qt5 instead of hardcoding the path.
Assuming the sources or the project are in a directory named src, you would configure the project with:
mkdir build
cd build
cmake -DQt5_DIR:PATH=/Volumes/Dashboards/Support/Qt5.9.1/5.9.1/clang_64/lib/cmake/Qt5 ../src/
src/CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(MyProject)
set(CMAKE_CXX_STANDARD 14)
# Suggestions:
# (1) EXECUTABLE_OUTPUT_PATH is deprecated, consider
# setting the CMAKE_*_OUTPUT_DIRECTORY variables
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/build)
set(CMAKE_MACOSX_BUNDLE 1)
set(CMAKE_INSTALL_RPATH "#executable_path/../Frameworks")
# Suggestions:
# (1) Do not hardcode path to Qt installation
# (2) Configure the project specifying -DQt5_DIR
# See https://blog.kitware.com/cmake-finding-qt5-the-right-way/
# (3) By convention, "REQUIRED" is added at the end
find_package(Qt5 COMPONENTS Widgets REQUIRED)
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} PUBLIC Qt5::Widgets)
install(TARGETS ${PROJECT_NAME} DESTINATION . COMPONENT Runtime)
# Get reference to deployqt
get_target_property(uic_location Qt5::uic IMPORTED_LOCATION)
get_filename_component( _dir ${uic_location} DIRECTORY)
set(deployqt "${_dir}/macdeployqt")
if(NOT EXISTS ${deployqt})
message(FATAL_ERROR "Failed to locate deployqt executable: [${deployqt}]")
endif()
# Execute deployqt during package creation
# See https://doc.qt.io/qt-5/osx-deployment.html#macdeploy
install(CODE "set(deployqt \"${deployqt}\")" COMPONENT Runtime)
install(CODE [===[
execute_process(COMMAND "${deployqt}" "${CMAKE_INSTALL_PREFIX}/MyProject.app")
]===] COMPONENT Runtime)
set(CPACK_GENERATOR "DragNDrop")
include(CPack)
This is my first time asking a question, so please be chill if I do something wrong.
Hello,
My Visual Studio solution is generated by CMake.
Code is in C++ (and QML).
I'm creating a QtQuick window which uses .qml files to generate its content.
When I run the built application from Visual Studio (2017 RC) the app gives a common
"Component not ready" error message.
But if I run the same .exe file manually, everything is working perfectly.
I suspect it must be some kind of a mistake in my CMakeLists causing Visual Studio searching for files in the wrong place but I have no idea what that mistake could be.
C++ code fail part:
...
QQmlComponent guiComponent(qmlEngine,
QUrl::fromLocalFile(APP_RESOURCES"/qml/GUI.qml"));
guiRoot = qobject_cast<QQuickItem *>(guiComponent.create());
guiRoot->setParentItem(mainWindow->contentItem());
qDebug() << guiComponent.errors();
...
My CMakeLists:
cmake_minimum_required(VERSION 3.8)
set(PROJECT_NAME "[MyProjectName]")
set(APP_NAME "[MyProjectName]")
project(${PROJECT_NAME})
set(CMAKE_AUTORCC ON )
set(CMAKE_AUTOUIC ON )
set(CMAKE_AUTOMOC ON )
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules;${CMAKE_MODULE_PATH}")
find_package(Qt5 REQUIRED Quick QuickWidgets)
find_package(QtImageLoader REQUIRED HINTS ${CMAKE_SOURCE_DIR}/addons/QtImageLoader/cmake)
find_package(AssimpModelLoader REQUIRED HINTS ${CMAKE_SOURCE_DIR}/addons/AssimpModelLoader/cmake)
find_package(GPUEngine REQUIRED geGL geSG)
set(SRC_ROOT "${CMAKE_SOURCE_DIR}/src")
set(SRC_FILES "")
set(INCLUDE_DIRS "")
add_subdirectory(src)
list(APPEND SRC_FILES ${src_SRC_FILES})
list(APPEND INCLUDE_DIRS ${src_INCLUDE_DIRS})
message("Located source files:")
FOREACH(_FILE ${SRC_FILES})
message("- ${_FILE}")
ENDFOREACH()
message("Located include directories:")
FOREACH(_DIRE ${INCLUDE_DIRS})
message("- ${_DIRE}")
ENDFOREACH()
source_group(TREE ${SRC_ROOT} PREFIX "src" FILES ${SRC_FILES})
add_executable(${APP_NAME} ${SRC_FILES})
target_include_directories(${APP_NAME} PUBLIC ${INCLUDE_DIRS})
target_link_libraries(${APP_NAME} Qt5::Quick Qt5::QuickWidgets geGL geSG AssimpModelLoader QtImageLoader)
set_target_properties(${APP_NAME} PROPERTIES COMPILE_DEFINITIONS "APP_RESOURCES=\"Data\"")
set_property(TARGET ${APP_NAME} PROPERTY FOLDER "${APP_NAME}")
add_custom_command(TARGET ${APP_NAME} POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory "${CMAKE_SOURCE_DIR}/libs/$<CONFIG>"
"$<TARGET_FILE_DIR:[MyProjectName]>"
COMMAND ${CMAKE_COMMAND} -E copy_directory "${CMAKE_SOURCE_DIR}/resources"
"$<TARGET_FILE_DIR:[MyProjectName]>/Data"
)
Edit: I had this problem for a long time now (months) and didn't bother to fix it because running the application manually was sufficient. But now I want to use Visual Studio's debugging tools and I can't.
Adding
VS_DEBUGGER_WORKING_DIRECTORY "$(OutDir)"
to my target properties like this
set_target_properties(${APP_NAME} PROPERTIES COMPILE_DEFINITIONS "APP_RESOURCES=\"Data\""
VS_DEBUGGER_WORKING_DIRECTORY "$(OutDir)")
fixed the issue.
For additional solutions, look at vre's comments above.