Conversation
|
Currently getting Not sure if that is related to my changes or not. I'll run some tests without my changes as well error: no member named 'numeric_limits' in namespace 'std' |
|
nice work, please test build apk |
|
Those errors do appear to be related to the :/ I need to figure out what the cause of this error is: |
|
So it looks like the builds that Debian provide have patched headers and source files. |
|
qt5.15.18 is out, why are you targeting .2? |
| ENV PATH=/opt/Qt/$QT6_VERSION/gcc_64/bin:$PATH | ||
| ENV LD_LIBRARY_PATH=/opt/Qt/$QT6_VERSION/gcc_64/lib | ||
| ENV QT_PLUGIN_PATH=/opt/Qt/$QT6_VERSION/gcc_64/plugins | ||
| ENV QTDIR=/opt/Qt/$QT6_VERSION/gcc_64 |
There was a problem hiding this comment.
Will these declarations overwrite the Qt5 ones? I think they're maybe not needed.
There was a problem hiding this comment.
That is a good point.
They will be overriding the Qt5 ones.
We will likely need to generate the bindings for each major version in a separate step?
There was a problem hiding this comment.
The LD_LIBRARY_PATH and QT_PLUGIN_PATH are used by Qt apps at runtime to find their needed .so files. The PATH and QTDIR are only needed so that a developer can more easily run qmake.
I think Genbindings doesn't need any of those four, it should only need the Qt5Root change in config-libraries.go plus the new PKG_CONFIG_PATH entries.
a
https://download.qt.io/online/qtsdkrepository The packages are provided by Qt project/The Qt company, not by aqtinstall project. |
|
The Qt company doesn't have opensource releases for anything newer than 5.15.x |
|
There may be a route forward, the debian patches are in their got. We could maybe pull down their patches for the release we're building against and apply any patches for headers we parse? |
|
Regarding To use the 5.15.2 headers, another solution would be to put I think there are Qt 5.15.16 prebuilt binaries available in the https://download.qt.io/archive/qt/5.15/ directory, although they're not separated by target OS, so perhaps aqtinstall can't find them. |
I think those are all source files actually. Just took a look and it seems like they might be |
|
Whilst I understand the idea, can we please ensure that we can still target the installed instance of Qt6 as an option? Having to purposefully target a specific release for each build makes this less friendly for downstream Linux distributions, since they are going to want whatever is shipped, not having to explicitly target a particular Qt release. |
This PR starts to switch to using aqt to target specific versions of Qt instead of relying on the version the distro provides