qt5base-lts/config.tests/arch/arch.pro

CONFIG -= qt debug_and_release
# Detect target by preprocessing a file that uses Q_PROCESSOR_* macros from qprocessordetection.h
COMMAND = $$QMAKE_CXX $$QMAKE_CXXFLAGS -E $$PWD/arch.cpp
# system function converts newline in output into spaces
COMPILER_ARCH = $$system($$COMMAND)
# Message back to configure so that it can set QT_ARCH and QT_HOST_ARCH
message($$COMPILER_ARCH)
Remove -arch argument and #define QT_ARCH from configures Do not try to detect the host or target architectures using uname or similar, and do not override with the -arch or -host-arch configure arguments. The configures will still accept the -arch and -host-arch arguments, but it ignores them and instead outputs a warning stating that these arguments are obsolete and should not be used. Set QT_ARCH and QT_HOST_ARCH qconfig.pri variables based on the compiler target. This is done by running qmake (twice when cross-compiling) on config.tests/arch/arch.pro, which preprocesses a file that contains all knowns processors. On Windows, configure.exe has never run any config.tests before, and does not currently have a function to run a program and capture its output. Use _popen() to accomplish this (as qmake does for its system() function). This needs to be done after qmake is built, as does the mkspecs/qconfig.pri generation. As a side effect, the configure steps have been slightly re-ordered, but the overall result is the same. The displayConfig() call is moved to just before generating Makefiles, so that it can show the detected architecture(s). Change-Id: I77666c77a93b48848f87648d08e79a42f721683f Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com> 2012-02-14 09:01:17 +00:00			`CONFIG -= qt debug_and_release`
			`# Detect target by preprocessing a file that uses Q_PROCESSOR_* macros from qprocessordetection.h`
			`COMMAND = $$QMAKE_CXX $$QMAKE_CXXFLAGS -E $$PWD/arch.cpp`
Make architecture detection more robust. Any message/error in mkspecs or qmake feature files ends up confusing the current arch detection logic. Instead, search for "Project MESSAGE: .* Architecture: <arch>". Change-Id: I308932a5b75f3a1fcbc4fe30c74faf2e83b2d752 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com> 2012-03-21 04:01:20 +00:00			`# system function converts newline in output into spaces`
			`COMPILER_ARCH = $$system($$COMMAND)`
Remove -arch argument and #define QT_ARCH from configures Do not try to detect the host or target architectures using uname or similar, and do not override with the -arch or -host-arch configure arguments. The configures will still accept the -arch and -host-arch arguments, but it ignores them and instead outputs a warning stating that these arguments are obsolete and should not be used. Set QT_ARCH and QT_HOST_ARCH qconfig.pri variables based on the compiler target. This is done by running qmake (twice when cross-compiling) on config.tests/arch/arch.pro, which preprocesses a file that contains all knowns processors. On Windows, configure.exe has never run any config.tests before, and does not currently have a function to run a program and capture its output. Use _popen() to accomplish this (as qmake does for its system() function). This needs to be done after qmake is built, as does the mkspecs/qconfig.pri generation. As a side effect, the configure steps have been slightly re-ordered, but the overall result is the same. The displayConfig() call is moved to just before generating Makefiles, so that it can show the detected architecture(s). Change-Id: I77666c77a93b48848f87648d08e79a42f721683f Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com> 2012-02-14 09:01:17 +00:00			`# Message back to configure so that it can set QT_ARCH and QT_HOST_ARCH`
			`message($$COMPILER_ARCH)`