I have a project and I need to prepare a CMakeLists.txt file for it.
I also have tests which I need to get an executables for after building the project.
Tests are located in a separate backEndTest folder with their own CMakeLists.txt file.
In order to achieve that I decided to use qtwindeploy tool for that. However, when I compile everything and try to run backEndText.exe file I have errors related to missing dlls.
That's what my main CMakeLists.txt file looks like:
add_subdirectory(backEndTest)
find_package(QT NAMES Qt6 Qt5 REQUIRED COMPONENTS Test)
find_package(Qt${QT_VERSION_MAJOR} REQUIRED COMPONENTS Test)
set(QtBinDir "C:/Qt/6.2.3/mingw_64/bin")
set(winDeploy "${QtBinDir}/windeployqt.exe")
set(backEndTest ${CMAKE_BINARY_DIR}/backEndTest/backEndTest.exe)
set(testBackEnd TRUE)
if (testBackEnd)
execute_process(COMMAND ${winDeploy} ${backEndTest} --compiler-runtime )
endif()
Do you have any idea why dlls are not getting linked?
Related
I'm porting a Qt project to CMake and after adding set(CMAKE_AUTOUIC ON) I've started experiencing a bunch of compilation problems, which are triggered when trying to compile mocs_compilation.cpp, such as error C2504: 'Lucene::Reader': base class undefined.
After looking into mocs_compilation.cpp, I've found that the file is nothing more than a long list of #include statements bundling source files into a huge translation unit.
CMake's documention mentions the following about mocs_compilation.cpp;
(...)
Not included moc_.cpp files will be generated in custom folders to avoid name collisions and included in a separate <AUTOGEN_BUILD_DIR>/mocs_compilation.cpp file which is compiled into the target.
(...)
With this in mind, how does AUTOMOC determine which files go into mocs_compilation.cpp? And is there any way to keep source files out of mocs_compilation.cpp and build them separately?
I've looked at similar questions but haven't found one for this basic scenario. I'm relatively new to CMake. I have a CMake-based Qt 5 project. It's a simple test application; during its build I want to build and statically link the open-source Paho MQTT C lib and the C++ wrapper for it. Those are two separate projects with their own CMakeLists.txt files.
Per Qt's default, it builds into a directory outside the source tree.
I've copied the source trees for these open-source libs under the parent directory of my project, and edited the top-level CMakeLists.txt file to add_subdirectory them.
I also added target_link_libraries. I can get the C lib by itself to build and link into the parent project, but if I add the C++ wrapper, the processing for the C++ wrapper complains that it can't find the C lib... which is true because it hasn't been built yet. A similar complaint for the C lib was solved by simply using Qt's "build all projects" menu item, but that doesn't work when the C++ wrapper lib is added. The wrapper's CMakeLists.txt files issues this:
CMake Error at paho.mqtt.cpp/src/CMakeLists.txt:150 (message):
Could not find Paho MQTT C library
And sure enough it doesn't exist because it has not been built when this preprocessing is done.
UPDATED: Here's my top-level CMakeLists.txt file, revised per Corristo's suggestion, which was successful in getting CMake to parse the entire hierarchy. The project now builds. I'm perplexed that the last two lines here result in an empty string, though. So does a similar attempt for the link directories.
find_package(QT NAMES Qt6 Qt5 COMPONENTS Widgets REQUIRED)
find_package(Qt${QT_VERSION_MAJOR} COMPONENTS Widgets REQUIRED)
set(PROJECT_SOURCES
main.cpp
mainwindow.cpp
mainwindow.h
mainwindow.ui
task.h
task.cpp
task.ui
)
if(${QT_VERSION_MAJOR} GREATER_EQUAL 6)
qt_add_executable(MQTTTest
${PROJECT_SOURCES}
)
else()
if(ANDROID)
add_library(MQTTTest SHARED
${PROJECT_SOURCES}
)
else()
add_executable(MQTTTest
${PROJECT_SOURCES}
)
endif()
endif()
add_subdirectory(paho.mqtt.c)
set(PAHO_MQTT_C_LIB paho-mqtt3a)
set(PAHO_MQTT_C_PATH "${CMAKE_CURRENT_LIST_DIR}/paho.mqtt.c")
add_subdirectory(paho.mqtt.cpp)
target_link_libraries(MQTTTest PRIVATE Qt${QT_VERSION_MAJOR}::Widgets)
target_link_directories(MQTTTest PUBLIC
"${CMAKE_CURRENT_LIST_DIR}/build/paho.mqtt.c/src"
"${CMAKE_CURRENT_LIST_DIR}/build/paho.mqtt.cpp/src")
target_link_libraries(MQTTTest PUBLIC paho-mqtt3a)
target_link_libraries(MQTTTest PUBLIC paho-mqttpp3)
target_include_directories(MQTTTest PUBLIC
"${PROJECT_BINARY_DIR}"
"${CMAKE_CURRENT_LIST_DIR}/paho.mqtt.c/src"
"${CMAKE_CURRENT_LIST_DIR}/paho.mqtt.cpp/src")
get_property(inc_dirs DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
message("Top-level include dirs = ${inc_dirs}")
It is a bit of a hack, but you can use the fact that the CMake find_* commands don't perform a search if the result variable is already set.
From the paho.mqtt.cpp/src/CMakeLists.txt file we find that the output variable for find_library is called PAHO_MQTT_C_LIB and the include directory is expected to be in PAHO_MQTT_C_INC_DIR, which in the original CMakeLists.txt from version 1.0.0 (which seems to be the version you're using) is itself computed from PAHO_MQTT_C_PATH.
Setting these two variables between the two add_subdirectory calls should then make this work:
add_subdirectory(paho.mqtt.c)
set(PAHO_MQTT_C_LIB paho-mqtt3a)
set(PAHO_MQTT_C_PATH "${CMAKE_CURRENT_LIST_DIR}/paho.mqtt.c")
add_subdirectory(paho.mqtt.cpp)
This makes use of the fact that target_link_libraries can be called both with library files (which is what the original paho.mqtt.cpp project expected) and with existing CMake targets (which is what we replaced it with). Linking to a CMake target also automatically introduces a build-order dependency, so this simultaneously ensures that the c library is built before the cpp library.
However, since this relies on the names of the variables used in the paho.mqtt.cpp project as well as the target name of the library target in the paho.mqtt.c project this can break any time you update one of these libraries to a newer version.
I have a QT Project I am working on, it has a couple of sub-modules, which I list in my project's .pro file as:
if(!include(module/my_module.pri)){
error("module my_module not found")
}
What I tried:
Well, I have found a library which I intend to use, which is a CMake project libcrashreporter-qt. I am just linking the project for completeness - there is nothing wrong with this library (to my knowledge)
Problem:
I figured I will try an include the CMakeLists.txt file as I would a .pri file:
if(!include(libcrashreporter-qt/CMakeLists.txt)){
error("module libcrashreporter-qt not found")
}
where the libcrashreporter-qt folder is in the root of my project
Some Code:
In doing so, I get a horde of compiler errors:
$project_dir/libcrashreporter-qt/CMakeLists.txt:1: 'project' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:2: 'cmake_minimum_required' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:4: Extra characters after test expression.
$project_dir/libcrashreporter-qt/CMakeLists.txt:5: 'cmake_policy' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:6: 'endif' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:10: 'find_package' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:12: Opening parenthesis without prior test name.
$project_dir/libcrashreporter-qt/CMakeLists.txt:16: 'string' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:17: 'string' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:18: 'endif' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:20: 'add_subdirectory' is not a recognized test function.
$project_dir/libcrashreporter-qt/CMakeLists.txt:21: 'add_subdirectory' is not a recognized test function.
CMake file content (note, I changed the file slightly trying to resolve build issues by removing the multi-line if-statement and commented the option line):
project(libcrashreporter-qt)
cmake_minimum_required(VERSION 3.1)
if(POLICY CMP0071)
cmake_policy(SET CMP0071 NEW)
endif()
#option(ENABLE_GPL_CODE OFF)
find_package(Qt5 COMPONENTS Core Network Widgets)
if((CMAKE_COMPILER_IS_GNUCXX AND CMAKE_CXX_FLAGS) OR (UNIX AND NOT APPLE AND CMAKE_CXX_COMPILER_ID MATCHES "Clang"))
# Breakpad uses GNU compiler extensions like typeof.
# Luckily these features are not used on OSX, so we can build the
# crashreporter there with the normal C++11 standard.
string(REPLACE "-std=c++11" "-std=gnu++11" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
string(REPLACE "-std=c++14" "-std=gnu++14" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
endif()
add_subdirectory(3rdparty)
add_subdirectory(src)
This leads me to believe there is an issue with Qt .pro file compatibility and CMake projects being used within each other.
Question:
How can access the library functions of this CMake project, and compile it with my project (i.e. w/o changing the CMake project itself), or alternatively how best can I convert the CMake project to a compatible .pro project?
AFAIK CMake and QMake cannot be mixed together in one project, they are two different build systems and if you want to use a CMake project in a QMake project you have "two" options:
if you want to use the source files (.cpp and .h) or even modify them in your project you have to import them to your QMake project (you can easily do that in your QtCreator) and compile all of the files of your project
if the CMake library that you are using doesn't need any change (most of the times it's like this when you're using a third party library) and you just want to import it to your project and link it against your executable, you just run and compile the CMake project (separate from your own QMake project) and then use the output dynamic or static library of that project to link against your QMake project
As far as I remember, in Qt you can specify the custom compiler settings for the extra target, so, if you need your CMake project to be rebuilt just before the target Qt application is built, you can try to use this way
A possible solution is here:
https://stackoverflow.com/a/15766946/2333496
I am using Qt in a way that the Qt-related files are in a separate subdirectory GUI, and I am using CMake file, the relevant part of it shown below. Basically this setup works, but when I add a new file (something like an own widget), the new file compiles OK, but in the linking phase the new object is not found. I used to delete the build subdirectory, and after that everything works fine. So, my question: do I wrong something with CMake? (I quess the symptoms are caused by some caching problem)
include_directories(${Qt5Widgets_INCLUDES} GUI/include main/include)
add_definitions(${Qt5Widgets_DEFINITIONS})
file(GLOB_RECURSE QOBJECT_HEADERS
"GUI/include/*.h"
)
file(GLOB_RECURSE QOBJECT_SOURCES
"GUI/*.cpp"
)
QT5_WRAP_CPP(hdr_moc ${QOBJECT_HEADERS})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS} -std=c++11 -Wall")
add_executable(simGUI main/sim_GUI.cpp ${QOBJECT_SOURCES}
${hdr_moc})
# Use the Widgets module from Qt 5.
target_link_libraries(simGUI Qt5::Widgets)
From CMake doc:
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
The typical approach is to list all files manually.
I have been searching about this for a couple of hours but couldn't find a solution, so asking.
I have a solution of projects that includes about 10 projects. But I'm facing a dependency problem. One of my projects generates moc files (QT moc file that was generated by 'QT4_WRAP_CPP' macro of Cmake) and I would like to use this moc file in another project. For now, after running the cmake script and getting the solution, I build all projects and the project that need those moc files generated by previous project complain about linking errors(rightly because I didn't point any file to it in its c-make script in ADD_EXECUTABLE section).
My question is: is there any way to add a 'not built yet but will' file to a project in Cmake to point it meanwhile writing the cmake script?
Here is related section of the cmake script of the project:
//suppose that X projects (which is also in this solution and built before Y project) generates a moc file with the name 'moc_X.cxx'
SET(Y_WORK_STATION_UI_HEADER YWorkStation.h
YSignInWidget.h
YConfigurationWidget.h)
QT4_WRAP_CPP(MOCSrcs ${Y_WORK_STATION_UI_HEADER})
ADD_EXECUTABLE(${PROJECT_NAME}
main.cpp
.
.
.
${MOCSrcs}
%---------------->and here something like moc_X.cxx ?
}
Hope it is clear enough. Thanks in advance.
If the file is generated by something CMake understands (that is, by a custom command in the same CMakeList), you can just list it and CMake will pick up the dependency by itself. For other cases, there is a source file property GENERATED which you can set on the source file to indicate it will be generated during build:
add_executable(${PROJECT_NAME}
main.cpp
.
.
.
${MOCSrcs}
moc_X.cxx ?
)
set_property(SOURCE moc_X.cxx PROPERTY GENERATED TRUE)
You seem to be doing several wrong things.
To start:
What do you mean by 'another project'? Do you actually mean 'another target'?
Why is one project using the moc files of another project? Is it also using the source files of that project? Why?
Why don't you use a static (or other) library if that's your goal? If using the source files of the other project makes sense for some reason (I imagine creating a unit test), then you should probably re-moc the files instead of trying to grab them from another implementation-detail location.