-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make mingw-w64-qt5-* packages work with QBS #59
Comments
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
I'll switch back to modifying the existing
|
Just successfully compiled the QML example from https://github.com/qbs/qbs :-) For testing without recompiling everything, I used the following hack:
|
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Should work now if you create that symlink manually. Note that the symlink can't be part of the package because it would defeat the point of renaming the library in the first place (point is to avoid conflicts with Qt 4 version). |
@Martchus awesome. will try this one out for a personal project. Had to finally manually compile mxe with qt (takes like 4-6 hours on my laptop but was the only way i could find) for the work project. I hope with Qt 6 trying to move away from qmake, there will be a better to maintain this without symlinks etc.. (This thread may interest you: http://lists.qt-project.org/pipermail/development/2018-July/033100.html - feel free to chime in about cross compilation headaches) The docker container we are using for that is created by:
Where launch is just a script to create the current user/group etc.. inside the container for fewer permission change headaches
Then to compile:
|
@saidinesh5 Thanks for sharing. I'm aware of that mailing list. Note that the symlink problem is actually self-introduced by one of my patches and not the fault of any particular build system. However, the patch is needed to prevent the package to conflict with And this is true for most of the patches. You could drop them, but some use-cases wouldn't be possible then. For instance the static configuration provided here as If the support for such use-cases is missing, I suppose I'll have to patch it myself regardless which build system is used. BTW, I'm wondering what's so bad about qmake. If Qt would consider my use-cases and support them I'm fine with qmake. CMake is my favorite build system and support for it is already good in general. So no complaints here, too. |
@Martchus Ahh I see. And Yep, Even I am surprised how Qt doesn't support static builds that well - eventhough that would definitely mean more business for them - given their licensing and all that. And The big problem with qmake for them started out as having to parse the project files for the QtCreator integration. They kept hitting edge cases and bugs. That's why they were looking for a new build system and then built qbs - because they already have a parser for QML language. The Qt 6 build system issue is also about what build system to use to build Qt itself - instead of their current bootstrapping code. Personally my stance on build systems is that the C/C++ community would be in a much better place if they dropped all the build systems tomorrow and standardize one as the defacto system. I may even welcome auto-hell-tools with openarms if it will end our build system wars once and for all. CMake seems pretty decent these days though. Especially with modern C++ libraries (Check out https://docs.hunter.sh/en/latest/ and https://conan.io/ if you haven't already - they are quite nice). IDE integration via. CMake server mode is quite nice too these days in most IDEs. |
Likely those use-cases are already covered by using MSVC where a full static build is supported AFAIK. Let's see how they decide about the build system. Personally I'm even fine with continuing to use qmake and just fix the broken parts (eg. dealing with dependencies of static plugins). For my own projects I prefer to use CMake so changing to CMake would also be welcome from my side. The possibility to re-use tools like |
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Just to give this thread a conclusion: http://blog.qt.io/blog/2018/10/29/deprecation-of-qbs So I'm not going to put any more effort into QBS support. |
As I posted elsewhere, "One small build system dropped for C++, One Giant Leap for C++ community!" |
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I4c9b3c170ed13943abe0d8b397a8cb9e360538b6
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I127bb0516bd4acfea588a5d48c46811525a8fca8
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I94f5a6c44c112bd44a84f802712077bc14782b4c
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I94f5a6c44c112bd44a84f802712077bc14782b4c
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I94f5a6c44c112bd44a84f802712077bc14782b4c
Adding a new, separate mkspec instead of patching the existing one might be the cleaner solution. However, tools like windeployqt and qbs do checks based on the hardcoded mkspec name to detect MinGW. So for this to work, the mkspec must be called win32-g++. Also see the following issues: * Martchus/PKGBUILDs#59 * Martchus/PKGBUILDs#60 Change-Id: I94f5a6c44c112bd44a84f802712077bc14782b4c
Setting up QBS for cross compiling with mingw-w64 should likely work using the following steps:
Working around the issue of locating the PRL files by creating symlinks does not help. In this case QBS will still treat the Qt libraries as Linux build.
So obviously QBS does not treat the Qt version provided in this repository as Windows version. I belief this is because my mkspec is called
mingw-w64-g++
and notwin32-g++
. (I use my own mkspec because there are a few adjustments needed for the mingw-w64 environment provided by the Arch Linux AUR packages.) At least I found some checks in the QBS sources where the mkspec name is used:Possible solutions:
win32-g++
mkspec rather than introducing a new oneThe current approach to merge shared and static library trees also prevents to use the static version with QBS. In fact, it would be nice to be able to customize the search pattern used to locate the PRL files like it can be done with qmake to support this use-case.
The text was updated successfully, but these errors were encountered: