Package Details: mingw-w64-qt5-tools 5.9.1-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-qt5-tools.git (read-only)
Package Base: mingw-w64-qt5-tools
Description: A cross-platform application and UI framework (Development Tools, QtHelp; mingw-w64)
Upstream URL: https://www.qt.io/
Licenses: custom, GPL3, LGPL3, FDL
Groups: mingw-w64-qt5
Submitter: ant32
Maintainer: Martchus
Last Packager: Martchus
Votes: 5
Popularity: 0.000000
First Submitted: 2013-08-28 23:58
Last Updated: 2017-07-06 21:17

Pinned Comments

Martchus commented on 2016-07-10 19:40

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs
There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff

For general discussion and issues not only concerning this Qt module in particular please use the comment section of the package mingw-w64-qt5-base.

Latest Comments

Martchus commented on 2017-02-12 15:03

According to thiago on #qt-labs IRC channel qcollectiongenerator is supposed to run on target so my suspicion is not correct:
[15:46] <thiago> [03:41:01] martchus: qcollectiongenerator is expected to be run in the target platform. Not on host

However, then the provided CMake file doesn't make any sense at all. At least I don't see any use case for it. I mean when cross-compiling we only configure and build under Arch Linux and hence your mingw-w64-cmake package is just a wrapper for Linux version and does not contain any binaries to run on the target.

But what's your use-case for this, I mean, how do you want to use it?

Martchus commented on 2017-02-11 21:22

xantares: This problem seems to exist since at least version 5.5.0 of this package, just nobody noticed it. I am not sure what this qcollectiongenerator is supposed to do, but I suspect this tool is required at build time. This would mean the path is actually correct, but the tool needs to be provided as native GNU/Linux binary. You obviously know more about qcollectiongenerator than me since you're trying to use it, so would this make sense? And where is it actually used?

xantares commented on 2017-02-11 16:05

Hi,
There'a problem when using the qt5help cmake config file:
for example in /usr/i686-w64-mingw32/lib/cmake/Qt5Help/Qt5HelpConfigExtras.cmake
there is:
set(imported_location "${_qt5Help_install_prefix}/lib/qt/bin/qcollectiongenerator")
but no /usr/i686-w64-mingw32/lib/qt/bin/qcollectiongenerator is installed
I changed it to:
set(imported_location "${_qt5Help_install_prefix}/bin/qcollectiongenerator-qt5.exe")
Same for qhelpgenerator
what do you think ?

Martchus commented on 2017-01-04 22:42

@Schala Here's a version of mingw-w64-qt5-tools providing a regular CMake file for QtUiTools target: https://github.com/Martchus/PKGBUILDs/commit/0b2216ecb8b20c7c813c78a0f5b3c1c74f03d316

This solution isn't nice and I haven't tested it. Which package/project uses this target? Would be useful for me to know so I can reproduce the issue.

BTW: I'm quite curious what you're actually doing with all those mingw-w64 KF5 packages. If you have PKGBUILDs for building actual KDE apps like Kate, Konversations or Okular (KF5 version works quite well for me natively under Arch) I would be very interested :-)

Schala commented on 2016-12-31 22:33

hmm... weird

Martchus commented on 2016-12-31 14:16

@Schala I customized the build system to allow use of static version with CMake. To achieve this, I prefixed all CMake files and targets for static variant with 'Static'. This way you can even use the dynamic and the static variant in one project at the same time. The problem is now that UI tools is only available as static library and in consequence only the 'Static' prefixed version is available. I haven't thought about this and I'm currently not sure how to deal with this special case. Since use of static version with CMake is one of my use-cases I would only reluctantly drop the concerning patch in mingw-w64-qt5-base (0022-Allow-usage-of-static-version-with-CMake.patch). But maybe I can figure a way to handle this special case. Not sure why Qt5UiTools is only available as static lib anyways.

Schala commented on 2016-12-31 00:30

Qt5UiTools module seems to be absent. I verified it and there are no CMake files for it

Schala commented on 2016-12-29 03:37

Well, in attempting to build the KF5 packages that require mingw-w64-qt5-tools, it seems to use mingw-w64-extra-cmake-modules to call for the locale generation, which in turn calls Qt5::lconvert from QtLinguistTools CMake module. The path looks fine to me, so I have no clue what to make of it.

Martchus commented on 2016-12-29 00:53

@Schala The Qt5::lconvert target is used directly and not via a helper macro. Hence I can not amend its usage in the same way as for lupdate/lrelease to work around this strange CMake issue.

In which context do you use the Qt5::lconvert target? Maybe you can there apply the workaround mentioned in the last comment.

BTW: This looks like a CMake bug to me - not sure why only mingw-w64 version of the package is affected, though.

Martchus commented on 2016-12-29 00:42

@Schala Not using lconvert myself, so I didn't notice. Is there an error message? Can you provide a simple example? Did it work with previous version of the package?

I already had to fix lupdate/lrelease for unknown reason: https://github.com/Martchus/qttools/commit/77e3129a33d3297bddc514edb773bf30133fa838

Maybe just the same is required for lconvert.

All comments