I'm developing Qt application and now I want to do some I18N stuff. First problem I meet is that cmake doesn't know about command QT5_ADD_TRANSLATION(we are using cmake for building our project). I refer to QtLinguist Manual. When I met that problem, I also read threads like Unknown CMake command "QT5_CREATE_TRANSLATION" and qt4 to qt5 migration, but unluckily, I still stuck here.
My cmake version is 3.16 for Qt 5.15.2. If you need more informations, please let me know.
Besides, If there is an alternative way to accomplish I18N work in Qt with cmake, that is also fine. For example, I come up with add_custom_command with lupdate from qt, but don't success yet.
add_custom_command(OUTPUT ${TRANSLATIONS}
DEPENDS ${SOURCES}
COMMAND lupdate)
command won't execute. I'm still try it.
It should be something like this:
find_package(Qt5 COMPONENTS LinguistTools)
qt5_add_translation(OUTPUT_VAR your_translation.ts)
CMake functions/macros provided by Qt itself belong to some particular module so you need to find that module before using its functioncs.
Related
I want to use uWebSockets(UWS) in my C++ project to transfer images over the network. The setup will be running on multiple operating systems, so the best way of creating the build files seemed like using CMake.
However, I am new to CMake and having a hard time building UWS. I don't understand how to start working with the official repository on Windows 10, so I found another repository that includes a CMakeFiles.txt file and some of the dependencies (openssl, zlib, libuv, but it doesn't include uSockets for some reason). The root CMakeFiles.txt includes:
[...]
find_package(OpenSSL REQUIRED)
find_package(ZLIB REQUIRED)
find_path(LIBUV_INCLUDE_DIR uv.h)
find_library(LIBUV_LIBRARY NAMES uv uv1)
[...]
It looks straightforward, but when I try to run mkdir build && cd build; cmake .., it cannot find OpenSSL. Here is the error message it spits out:
[...]
[cmake] Could not find a package configuration file provided by "OpenSSL" with any
[cmake] of the following names:
[cmake]
[cmake] OpenSSLConfig.cmake
[cmake] openssl-config.cmake
[...]
The above error message suggests that I need to set up a config file for each of these libraries. Yet, if I understand the find_package docs correctly, the command itself searches the library in various locations under the root folder. What kind of a folder structure does the find_package need in order to work?
More generally, am I wasting my time with this alternative repo? Is there a better way of using UWS with Windows 10? The official repo has a question about how to use it on Windows but I don't understand how that's an answer to the question. It only points to this page where it says any specific build systems will not officially be supported.
Any help would be appreciated.
Importing dependencies with add_subdirectory seems like a good way around this. When I ran cmake, I was receiving LNK2019 Error. I realized the following code snippet I found online was causing the problem, and the system works when I delete it.
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS_DEBUG "${CMAKE_EXE_LINKER_FLAGS_DEBUG} /NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:msvcrt.lib")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:WINDOWS")
endif()
I have a gtest cmake project that can be compiled and debugged with kdevelop. Since version 4.5 kdevelop can handle unit tests. I do not find a way to integrate the tests to kdevelop "Unit-Tests". Does anybody know how to do it?
For test binaries to show up in the Unit-Tests tab in Kdevelop (tested on 5.3) you need to make your testcases be recognized by CTest.
If you have a dedicated CMakeLists.txt for your test-executable a minimal configuration could look like this:
set (SOURCES
testsource.cpp
)
add_executable(testexecutable ${SOURCES})
target_link_libraries(testexecutable
gtest
)
add_test(
NAME test
COMMAND testexecutable )
Additionally for it to be working with a standard CMake configuration run you need to add
enable_testing()
somewhere in your CMake project, eg. your main CMake file.
I found further documentation here:
https://cmake.org/cmake/help/latest/command/add_test.html
https://gitlab.kitware.com/cmake/community/wikis/doc/ctest/Testing-With-CTest
Be aware that this only adds basic execution of the testcase binaries to the KDevelop GUI. There is no customisation or/filtering in the GUI that I know of.
You may also have a look at the gtest specific defintions for cmake/ctest. I didn't try any of these as I'm stuck on a CMake version which does not support these yet.
https://blog.kitware.com/dynamic-google-test-discovery-in-cmake-3-10/
Qt Creator makes GUI creation ridiculously easy, but I would rather use CLion for the coding part, and only use Qt Creator for the GUI editing.
Definitely possible!
I'm on a mac, so there are a few things that I do that won't work the exact same for other operating systems. They're small, simple things that a bit of google-fu should fix relatively painlessly.
Step 1: Create a Qt Creator Project
I'll be using a widgets application for this example. I'll get to other types of projects a little later.
One thing that I would highly recommend is to change the build directory (under the Projects tab on the sidebar) to a relative path instead of an absolute one, especially if this is going into GitHub or the likes. I changed it to ./QtBinDebug.
Oh, and remember to copy or otherwise save in a separate location the contents of main.cpp for later.
That's it for Qt. We should only need to use Qt Creator when editing our GUI from now on.
Step 2: Open the project up in CLion
CLion need to create a few files in order to be able to work with our project. Tell CLion to make a new project, but name the project the exact same as the one we made in Qt Creator, and point CLion at the same path. It should warn you about files already existing, just ignore it.
CLion will have very helpfully overwritten main.cpp. Put what you copied from QtCreator back in there.
Step 3: Call the right Makefile
Qt Creator will actually generate it's own makefile that will call qmake, and do a whole bunch of other magic. It's insane... I can replace my existing CMakeLists.txt with
cmake_minimum_required(VERSION 3.3)
project(WindowTest)
set(QT_BIN "${PROJECT_SOURCE_DIR}/QtBinDebug")
add_custom_target(qtMakeFile COMMAND make -C ${QT_BIN})
This will build the project perfectly fine! The only problem is that CLion
only supports CMake projects right now. The above CMakeLists gets around that by telling CMake to just call make on the right makefile, but the IDE itself doesn't know how to interpret our code......
Step 4: Find out where the Qt libraries are installed
I installed Qt via Homebrew and found the libraries I needed at /usr/local/Cellar/qt5/5.5.1_2/lib/cmake. If you told Homebrew to link the installation, /usr/local/opt/qt5/lib/cmake will also work, and has the added benefit of keeping your Qt version up to date without needing to change anything!
Step 5: Linking in the Qt Libraries for CLion
If you're like me, you'd rather use CLion when it autocompletes everything and doesn't throw red text everywhere.
We need to tell CLion where to look for the libraries it's missing. For a basic Widgets project, I needed Qt5Core and Qt5Widgets. To see what you'll need for sure, check the makefile Qt Creator generated. You should find what you need near the top in the LIBS macro.
For the linking, we're going to be using the find_package(...) and target_link_libraries(...) commands. While we could hard-code everything into these two commands, I thought breaking it up a little would be a good idea.
One other small detail is the header file that Qt Creator places in the build directory. For a skeleton widgets project, it's ui_mainwindow.h. We can tell CLion where to look with an include_directories(...) command.
My CMakeLists.txt:
cmake_minimum_required(VERSION 3.3)
project(WindowTest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
#Base QT directory
set(QT_PATH "/usr/local/opt/qt5")
#Build output path of your QT Creator project
set(QT_BIN "${PROJECT_SOURCE_DIR}/QtBinDebug")
#Qt5 paths
#Qt5 library path
set(QT5_LIB_DIR ${QT_PATH}/lib/cmake)
#Qt5 individual libraries
set(QT5_CORE ${QT_LIB_DIR}/Qt5Core)
set(QT5_WIDGETS ${QT_LIB_DIR}/Qt5Widgets)
set(QT5_GUI ${QT_LIB_DIR}/Qt5Gui)
#Libraries to link to. The :: is for convenience
set(QT_LIBRARIES Qt5::Core Qt5::Widgets Qt5::Gui)
#Libraries required. Probably the same as above minus the '::'. find_package() will be called on these
set(QT_LIBRARIES_REQUIRED Qt5Core Qt5Widgets Qt5Gui)
#find packages
foreach(QT_LIBRARIES_REQUIRED ${QT_LIBRARIES_REQUIRED})
find_package( ${QT_LIBRARIES_REQUIRED} REQUIRED )
endforeach()
add_custom_target(qtMakefile COMMAND make -C ${QT_BIN})
include_directories(${QT_BIN})
set(SOURCE_FILES main.cpp mainwindow.cpp mainwindow.h mainwindow.ui)
add_executable(WindowTest ${SOURCE_FILES})
target_link_libraries(${PROJECT_NAME} ${QT_LIBRARIES})
Step 6: Setting up CLion to actually run the thing properly
There should be a configuration that popped up in the run configurations menu. For me, with the above CMake file, it's qtMakefile. We need to do one last thing with that target, so click "Edit configurations..."
We need to select the executable that CLion should run after building. In the section for Executable, click "Select other..." and select the widget's executable. Mine was in QtBinDebug/WindowTest.app/Contents/MacOS/WindowTest.
And that's it! Congratulations!
Downsides
Debugging doesn't work. The debugger isn't linking on a simple hello world I put into my test program. To be honest, though, I really don't want to go down that rabbit hole.
Upsides
Autocomplete out the wazoo
I'm using CMake to build a Qt application. My project compiles, and thanks to 'fixup_bundle()', make install copies the required libraries next to my executable. Great!
Only problem is, when I execute it, I get the dreaded 'This application failed to start because it could not find or load the Qt platform plugin "windows".' error.
Indeed, manually copying qwindows.dll into a 'platforms' directory next to the executable fixes the issue. Now, how can I tell CMake to do that automatically?
Not much info from Qt :
Plugins are also available as IMPORTED targets in CMake. The Qt Network, Qt SQL, Qt GUI, and Qt Widgets modules have plugins associated. They provide a list of plugins in the Qt5_PLUGINS variable.
All right, I guess I have to play with Qt5::QWindowsIntegrationPlugin, which should be an imported target. That's where I'm lost.
I know (well, I think I know at least) that fixup_bundle() looks into the executable to find its dependencies. But despite the fact that I link my executable against QWindowsIntegrationPlugin, there is no trace of it. Therefore, no qwindows.dll copied into my output path by fixup_bundle().
Except the manual copy of the file, I couldn't find a nice CMake-friendly answer to this issue.
Thanks for your help.
Just ran into the same issue. Here is how I resolved it in my CMake install script:
# QWindowsIntegrationPlugin is part of the Gui component
find_package(Qt5 COMPONENTS Gui REQUIRED)
install(
FILES "$<TARGET_FILE:Qt5::QWindowsIntegrationPlugin>"
DESTINATION bin/platforms
)
I want to install OpenTissue physics simulation library, and it requires boost.
There is a .bat file in the third_party/include directory which retrieves the required boost bindings. I've successfully ran the script and after that CMake.
However, the CMake 'Configure' states: "Could NOT find boost", even though it is in the directory where the authors of the script supposed it would be. After that, I've tried to manually set the BOOST_BINDING_PATH, as stated here: http://www.opentissue.org/mediawiki/index.php/Boost_bindings. But still, I cannot get the CMake to register the boost bindings.
Has anyone done this successfully?
OS: Windows 8.1
OpenTissue retrieved from: http://www.opentissue.org/svn/OpenTissue/sandbox
CMake: 2.8.12.2
If you know where Boost is, you could pass BOOST_INCLUDE_DIR and BOOST_LIBRARY_DIR when you run CMake, like so:
cmake -DBOOST_INCLUDE_DIR='path_to_boost_headers' -DBOOST_LIBRARY_DIR='path_to_boost_libraries'