I haven't solved the problem yet, but I know what caused it. QtCreator is doing what it's supposed to, that is, finding the 5.15.1 libraries correctly. My problem is that my Cutelyst version was built with Qt 5.12.8. CMake automatically found and used the Qt 5.12.8 libraries I have installed, which allowed the version built with only CMake to run correctly. So, I built a Cutelyst version manually using the 5.15.1 libraries instead. I'm having trouble getting CMake to detect that version, but that's a separate issue, so I'll close this one.

A hack that I had to do for this to work is to manually copy the so file. if(ANDROID) add_custom_command(TARGET cook-ui-modular-qt POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_BINARY_DIR}/App/ConnectedSocket/libConnectedSocket_${ANDROID_ABI}.so ${CMAKE_BINARY_DIR}/App/UserInterface/android-build/libs/${ANDROID_ABI}/libConnectedSocket_${ANDROID_ABI}.so ) endif() This is obviously not the right way to do it. But I don't know how to do it the right way

@Dmitriano reported this as a bug.

@Christian-Ehrlicher Got it working by myself now, but thanks anyhow for the quick reply. The problem was that i called cmake from within the source not the build dir so it ran cmake for a fresh new build that wasn't already setup from within Qtcreator and did not know where to search for Qt stuff. This is my script now: cd C:\Build\myQtApp\build_r cmake -S Y:/ -B C:/Build/myQtApp/build_r "-DBUILD_TYPE_1:BOOL=ON" "-DBUILD_TYPE_2:BOOL=ON" cmake --build C:/Build/myQtApp/build_r --target all -j2 ... cmake -S Y:/ -B C:/Build/myQtApp/build_r "-DBUILD_TYPE_1:BOOL=OFF" "-DBUILD_TYPE_2:BOOL=ON" cmake --build C:/Build/myQtApp/build_r --target all -j2 The boolean parameters BUILD_TYPE_1 and so on are used inside cmake to add a preprocessor defines that are then used to switch between different build configurations just in case anybody wants to know. In cmake: if(BUILD_TYPE_1) message(STATUS "Build Type: Type 1") add_definitions(-DBUILD_TYPE_1) endif() in c++ #ifdef BUILD_TYPE_1 ... #endif

So for clarity for anyone with the same question, the following CMakeLists.txt makes the class Person available to QML via import People, by packaging it behind the scenes as Peopleplugin. cmake_minimum_required(VERSION 3.16) project(MyProject VERSION 0.1 LANGUAGES CXX) set(CMAKE_AUTOMOC ON) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 6.2 COMPONENTS Quick REQUIRED) qt_add_executable(appMyProject main.cpp ) qt_add_qml_module(appMyProject URI MyProject VERSION 1.0 QML_FILES main.qml ) qt_add_qml_module(People URI People VERSION 1.0 SOURCES Person.h Person.cpp ) target_include_directories(Peopleplugin PUBLIC ${CMAKE_CURRENT_SOURCE_DIR} ) target_compile_definitions(appMyProject PRIVATE $<$<OR:$<CONFIG:Debug>,$<CONFIG:RelWithDebInfo>>:QT_QML_DEBUG>) target_link_libraries(appMyProject PRIVATE Qt6::Quick People) and for those eagle-eyed, main.qml was buggy and should be: import QtQuick import People Window { width: 640 height: 480 visible: true Text { text: personBob.name + " wears size " + personBob.shoeSize + " shoes." } Person { id: personBob name: "Bob Jones" shoeSize: 12 } } The C++ class Person is derived from QObject: #include <QObject> #include <QtQml/qqml.h> class Person : public QObject { Q_OBJECT Q_PROPERTY(QString name READ name WRITE setName NOTIFY nameChanged) Q_PROPERTY(int shoeSize READ shoeSize WRITE setShoeSize NOTIFY shoeSizeChanged) QML_ELEMENT ... main.cpp is as autogenerated when creating a new Qt Quick 6.2 project in Qt Creator and makes no mention of Person or the People plugin. Other C++ classes can #include "Person.h" and make use of the Person class.

@tuzepoito said in How do I use Qt headers in a CMake sub-project?: I think I have a solution, or maybe a workaround. Why workaround? If you want to use a library, you have to link against it what you're doing now - how should this be a workaround?

The second choice, same folder structure.

On the Raspberry Pi, in the terminal before running my application, I had to run export QML2_IMPORT_PATH=/usr/local/qt5.15/qml and that fixed it. I put that line in my ~/.profile and it seems to have fixed it permanently. I no longer have to run the export command manually.

@SGaist Yes, I forgot it. Fixed this by adding Svg: find_package(Qt6 COMPONENTS Core Gui Quick Qml Multimedia LinguistTools Svg REQUIRED) target_link_libraries(${PROJECT_NAME} PRIVATE Qt6::Core Qt6::Gui Qt6::Quick Qt6::Qml Qt6::Multimedia Qt6::Svg)

@Dmitriano How did you update the build.gradle

@jsulm Thank you very much! This is exactly the problem, I set up mingw in the environment variable, which caused me to compile MSVC Qt using MINGW

@Dariusz said in cmake automoc + dll... error LNK2001: unresolved external symbol "public: static struct QMetaObject: Do I have to write some kind of post build command that copies all moc files to some location & ship it with my dll/include folder? no, the moc data is compiled into your binary, like any other class/method etc. Since you are using cmake, did you set the AUTOMOC property?! https://doc.qt.io/qt-6/cmake-get-started.html

I was asking for the exact Qt version because of this: https://bugreports.qt.io/browse/QTBUG-97054

Thanks Guys.. helped me out alot :D

@BDC_Patrick might be a driver/win11 issue, does it also directly crash with a console application?

Yes, it is. But Qbs is better (IMHO), and you can use QtCreator && VSCode IDEs. ;) CMake it is pain...

I fixed this buy changing C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat with C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsx86_arm64.bat., see https://developernote.com/2021/09/how-i-fixed-cmake-configuration-has-no-path-to-c-compiler-in-qt-creator/

Well, there's nothing to fix, the output matches what your test does.

Do you mean how to add paths so that your .exe files can be run from Qt Creator, or adding paths so that your .exe files can be run without Qt Creator? In the first case (starting .exe files from Qt Creator) as long as you only have a single version of Qt installed on your PC, there should be no need to add any paths, as I said earlier, Qt Creator adds the path to the Qt dlls for you. In the second case (starting .exe files without Qt Creator) then there are 2 ways to do it: copy the Qt dlls to the same directory that your .exe file is in, either manually or by using the windeployqt.exe program adding the path to the Qt dlls to the PATH env. variable Note: LIBS += -LMyPath has no effect on runtime lookup of .dlls or .so files QMAKE_RPATHDIR has no effect on Windows, because Windows does not support adding a list of paths to your .exe/elf file where to find the Qt dlls/so files (works only on Linux and MacOS) Also on Linux, QMAKE_RPATHDIR is not needed for the first case (starting .exe/elf files from Qt Creator) since Qt Creator does that automatically for you (by issuing a linker command e.g. -Wl,-rpath,/home/user/Qt/5.15.2/gcc_64/lib)

@VRonin said in How to properly configure QML import path in a C++ defined QML module in a cmake project?: set_target_properties(${PROJECT_NAME} PROPERTIES QT_QML_MODULE_VERSION 1.0 QT_QML_MODULE_URI com.cutehacks.duperagent ) qt6_qml_type_registration(${PROJECT_NAME}) Hi, thanks for the answer but sadly it did not work

Fixed. This errors was because of Qt 6. I downloaded and linked previous version of QT - 5.15, and this errors disappeared

@cube45 said in How to define initial build options with CMakeLists.txt: How do you publish your app then? 'make install' is your friend.

@JoeA-B said in PkgConfig cannot find directfb: Why not link? I am adding a module to a full operating system and cannot control the rest of the configuration still a simple -ldirectfb parameter should work on all systems, when the plugin is in a default lib directory (which /usr/lib/x86_64-linux-gnu is btw for example on Debian/Ubuntu)

Thank you to all the panellists, I’ll take care of it. Can we leave it open in case there are any mistakes or questions?

Sorry, I hadn't come back to trying this for a while. I was able to get past this by dropping -optimize-size, but ran into other strange issues, primarily where a purely debug build had a bunch of errors and a mixed config build would not create the debug lib files (likely due to the same cause, just the errors didn't show or halt the build for some reason) even though the process appeared to complete successfully. Not having much luck with Qt6 it seems, which is a shame since I'd really like to make use of the upstream changes I submitted for it. Luckily at this point MSVCs internal CMake version has been updated to one that is compatible with Qt6, so the manual replacement is no longer needed. I'm currently trying to build 6.1 and was able to get past the configure step, though I had to disable tests (which this time I wanted to confirm it built correctly) due to QTBUG-88829, so I'll see if I have better luck this time. If the mixed build doesn't work I'll try just a debug one again to see if there are the errors I had before, or if not so that I can compile tests and see what might be failing.

@noone said in QtFuture not found: workaround ? #include <QFuture>

AFAIK, it's the script that was used to bootstrap the port from qmake to cmake so it should do a pretty good job.

If possible maybe somebody could clone the repository and try it his computer to open project and run CMake. Not necessary to build the project (it may take 9 hours) but before launching CMake set build dir path as short as possible (I have build folder C:\S\b and the source C:\S\Slicer) because Slicer has some problems with path length and CMake will throw an error if build folder path is too long. I'm very interested in working on this project in QtCreator and not in Visual Studio but that QtCreator's behavior doesn't leave me any chances.

I find solution Your need to add qt path into CMAKE_FIND_ROOT_PATH variable. cmake -DCMAKE_FIND_ROOT_PATH=yuor/qt/path . i think that trouble in the android.toolchain.cmake file. This toolchain overwrite the CMAKE_PREFIX_PATH variable.

@noone said in no "Initial CMake parameters" field in Qt creator: what should I do ? Update to 4.13 :-)

This "solution" is just to enable syntax highlighting. Try the following very basic code: __global__ void hello() { printf("This is a test"); } int main(int argc, char* argv[]) { hello<<<1,1>>>(); return 0; } The code above is a very basic example for CUDA source file that includes a kernel definition and will cause a lot of problems with Qt Creator. I am guessing the same will happen if we use __device__. Adjusting the MIME type for C++ to include CUDA helps only with the syntax highlighting. Ultimately CUDA, while being very, very similar to C/C++, is a different language that requires its own language model that is not included in Qt Creator as well as a compiler, which - through CMake - can somewhat be integrated into the IDE. If you want to develop with CUDA and CMake I would suggest using VS Code or Visual Studio with the second still (2019 edition) having a not that great support for CMake). Last but not least the devs from NVidia have done a really sloppy job in regards to offering integration of the CUDA infrastructure in popular IDEs. It takes hours if not days to make a setup that just works.

@surferbrain You need to look inside that vcvarsall.bat file and see what paths it is trying to find/execute which cannot be found. Isn't the problem in your VS set up rather than Creator?

Well, huh. I thought I tried that one with the bigger project before, but it does work with the test program here, so that must have been something else. Thank you for your assistance.

@kdabros Hi! Did you manage to make a qmake based project for a VST plugin that you would like to share? I was just searching the forum for an example of that and your post was the closest thing I could find! Thank you, Ilias

@wokerjrvm How is your question related to the original question in this thread? Please open your own thread and ask there.