Qt 6

Hello
I am trying desperately to get this working, it is not.
I am not sure what I am doing wrong.
Is there a special path or something?
For some reason, it is not detecting Qt6
I am using Manjaro

I have created a bug report regarding this. I used the minimal example that you have created in the bug report. Thanks for sharing your minimal example.

https://bugreports.qt.io/browse/QTBUG-111968

@Cata123 if you need to set that variable, it means that the folder containing the plugins is not at the expected place.
The solution itself is not bad per se though.

Qt 4 has a different architecture for the platform backend part hence the "new" behaviour.

@pavanbellary But why cmake try to install it when it is not compilled and there are no errors at configure and at compilation.

@Habib123
you should put:
find_package(Qt${QT_VERSION_MAJOR} REQUIRED COMPONENTS Widgets PrintSupport)

and link with the finded library:

target_link_libraries(Test PRIVATE Qt${QT_VERSION_MAJOR}::Widgets PRIVATE Qt${QT_VERSION_MAJOR}::PrintSupport)

@Spazz have you solved the problem? It seems tha I met the same trouble that the vertexCount is alway 0.

@fawad
Like @jsulm says, I don't use your environment but if I did I would hope to do everything inside and only use one of either Creator or Visual Studio, swapping between them sounds like a pain!

The fact that it's a 32 bit target is not an issue. Depending on the library, the harder is often to make its build system use the cross-compiler on the host (things have vastly improved on that side since I was doing embedded work).

See Examples, Tests, and Tools
and Third-Party Libraries

I'm running into this in windows. I've been looking at the qmake -d 2>&1 of a Qt example vs a QWT example. At some point in the QWT qmake generation it seems to loose the entrypoint_private module.

qt example: DEBUG 1: C:/tools/Qt/6.4.2/msvc2019_64/mkspecs/features/qt_functions.prf:379: modules := core gui entrypoint_private
qwt example: DEBUG 1: C:/tools/Qt/6.4.2/msvc2019_64/mkspecs/features/qt_functions.prf:379: modules := core gui printsupport concurrent opengl openglwidgets svg

I haven't been able to figure out the clean fix yet. I ended up diffing the makefiles between the examples and one the major differences was that the QWT example was missing the lib: Qt6EntryPoint.lib
So I added it to the qwt example pro like:
LIBS += C:\Qt\6.4.2\msvc2019_64\lib\Qt6EntryPoint.lib

and then the release version at least built successfully.

note: for diffing the qmake -d output it's handy to do a cut like this (powershell):
qmake -d 2>&1 | % { $_ -split ':' | select -last 1 }

this strips out a lot of paths making the diff easier to scan.
This was using Qwt 6.2.0, git sha:92baef.

@IceMichael said in Precompiled headers with CMake in Qt 6. How?:

Interesting would be to see how we can a wellformed list of Qt header names that can be used to pass to the CMake function

No since CMake don't know what headers you're using / you want to use. Even when you link against Qt::Widgets adding the <QtWidgets> header to the precompiled target may be wrong. Adding some important headers manually shouldn't be that big problem.

@sierdzio Thank you a lot for your answer !

Your explaination on the opaque pointer is clear, I didn't have that notion before.

With this knowledge, most of my questions are wrong, like the 5th.

@Asperamanca confirmed. Thank you so much!