Manage the HostInfo variable prefix the correct way. The prefix
takes the HostInfo PROJECT_VERSION_MAJOR as the version specifier,
which is not necessary is the same as the PROJECT_VERSION_MAJOR
of the project that uses respective API. Instead of relying on the
current PROJECT_VERSION, use the version info stored in HostInfo
package and adjust the prefix accordingly. This will allow version
mismatching between the project that uses API and HostInfo version.
Change-Id: Idbaec1c7bb203448ceb0f15c9173ad3985c7112d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 361d0b7222fd35133186571762640aada67fa39b.
The qmake behavior is fixed by b66ecb295ecc3981b1c21f01d62c9066f5d6e6ca
so that the original fix can be reinstantiated.
Pick-to: 6.8
Change-Id: I5338e4cbebc963f48469e7492f18375e56a46200
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit 7ae19cee1c782fadfbd0c617568fdad8aba9a493.
Reason for revert: breaks non-cross QMake builds on
Windows on ARM64. The QMake mkspec is now reported as
win32-arm64-msvc, and apparently, QMake is not prepared for this.
Pick-to: 6.8
Change-Id: I45c19719c6f0862580dbff09244337283305ee6c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In windows CMAKE_SYSTEM_PROCESSOR can be set to both arm64 and ARM64.
Make the comparison case-insensitive when defining mkspec.
Pick-to: 6.8 6.7 6.5
Fixes: QTBUG-127044
Change-Id: Id0c8f04bc0ec6b70993e400f9c285168d4c1499b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
My motivation to do this:
- it got big and tangled again
- sometimes functions need to be added to QtBuild.cmake rather than
to a separate file because they need to be called before some of the
global variables are set, to determine the value of those global
variables (in my case install paths needed to be modified when
building with xcframework support)
- some of the global variable assignments have dependencies on other
variables already being set and it's hard to keep track where that
happens
Split the contents of the file into smaller functions and macros
and place them into pre-existing files when appropriate, or
into new files. The new files are:
- QtBuildHelpers.cmake
- QtBuildPathsHelpers.cmake
- QtMkspecHelpers.cmake
The idea is to have Helpers file only define functions and never call
them, so it's easy to include the file where needed without being
scared of side effects.
QtBuild.cmake will just include the helpers and call one entry point
function to set up everything that was done by the file before.
QtBuild.cmake is not merged into QtSetup, to make it easier to git
blame (it's hard to blame a removed file).
No new features were added as part of the refactoring.
Some function names were renamed (but not all of them) to include
the qt_internal prefix.
Some lines were reformatted so they don't pass 100 chars limit after
the code was placed into a function / macro.
The Helpers includes were re-sorted.
Some function calls were re-ordered where the order call didn't
matter.
Some of the code in QtAndroidHelpers.cmake was wrapped into a macro
so that including the file does not cause side-effects by default.
I'd like to follow up with similar changes for QtSetup.cmake and
QtBuildInternalsConfig.cmake where possible, because having a few
"entry points" into building a Qt submodule is also confusing,
especially for those that aren't familiar with the build system and
why certain things go into certain places.
The intent is to cherry-pick this also to 6.5 and 6.6.
Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0
Task-number: QTBUG-86035
Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
