Commit Graph

10 Commits

Author SHA1 Message Date
Liang Qi
d7e4980132 Merge remote-tracking branch 'origin/5.8' into dev
Blacklist tst_QMenuBar::taskQTBUG46812_doNotLeaveMenubarHighlighted() on macOS.

Conflicts:
	mkspecs/features/mac/default_post.prf
	mkspecs/features/mac/sdk.prf
	mkspecs/features/uikit/default_post.prf
	mkspecs/features/uikit/sdk.prf
	src/angle/src/libEGL/libEGL.pro
	src/platformsupport/fontdatabases/fontdatabases.pro
	src/platformsupport/platformsupport.pro
	src/plugins/platforms/cocoa/qnswindowdelegate.mm
	src/plugins/platforms/direct2d/qwindowsdirect2dintegration.cpp
	src/plugins/platforms/ios/ios.pro
	src/plugins/platforms/ios/kernel.pro
	tests/auto/widgets/widgets/qmenubar/BLACKLIST
	tests/auto/widgets/widgets/qmenubar/tst_qmenubar.cpp

Task-number: QTBUG-56853
Change-Id: If58785210feee3550892fc7768cce90e75a2416c
2016-11-02 09:24:11 +01:00
Jake Petroules
d10c4f08d4 Be more robust about ensuring that device and simulator are set
These CONFIG entries are also needed during configure, and preemptively
fixes build errors uncovered by an upcoming forward merge, due to code
restructuring.

Change-Id: I39ae5e0f24bbd43dd3c04225d42cce4edd199094
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2016-10-28 12:38:02 +00:00
Oswald Buddenhagen
418494ecb6 fix QMAKE_DEFAULT_*DIRS resolution with apple SDK, take 2
the code got factored out to an own toolchain.prf file, which is
load()ed from default_pre.prf, so no change at first.
however, on mac, we shadow toolchain.prf, and make it load() sdk.prf
first.

a side effect, it has become harder to disable the use of an sdk
altogether: putting CONFIG-=sdk into a project file or the qmake
command line has no effect now. instead, it's possible to put it into
.qmake.{conf,cache}.
to make it simpler again, it's conceivable to finally add qmake -pre,
which would allow setting variables before default_pre.prf is executed.

take 2: there was nothing wrong with the original patch, but in 5.8,
CONFIG+=simulator_and_device moved from qconfig.pri to various prf files
that would do it according to the simulator_and_device configure
feature, which would be way too late for the "pulled ahead" sdk.prf
loading. as simulator_and_device is now gone entirely, it is safe to
re-apply this patch (mostly) as-is.

Task-number: QTBUG-56144
Change-Id: I6cf484982eaed8af39f7a539c60f5a087a299914
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2016-10-16 00:12:11 +00:00
Jake Petroules
4c26b48633 Allow Qt for UIKit to be built as shared libraries and default to it
Instead of forcing a static build, configure now respects the
-shared flag and defaults to that.

[ChangeLog][Important Behavior Changes] Qt for iOS now respects the
-shared configure flag, and now defaults to this configuration as with
all other platforms.

Task-number: QTBUG-42937
Change-Id: I9e7b2de8f7f8ba031c2610ff5ac0858e357424bd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-10-07 08:34:31 +00:00
Jake Petroules
397f345a6a Remove simulator_and_device handling for the Makefile generator
This patch moves towards a more sensible layout for UIKit platforms,
where both the device and simulator architectures for binaries are
combined into a single Mach-O file instead of separating out the
simulator architecutures into separate _simulator.a files.

This approach is both more common in the iOS ecosystem at large and
significantly simplifies the implementation details for Qt, especially
with the upcoming support for shared libraries on UIKit platforms.

This patch takes advantage of the -Xarch compiler option to pass the
appropriate -isysroot, -syslibroot, and -m*-version-min compiler and
linker flags to the clang frontend, operating in exactly the same way
as a normal multi-arch build for device or simulator did previously.
Exclusive builds are still enabled for the xcodebuild wrapper Makefile,
which builds all four configurations of a UIKit Xcode project as before,
as expected.

A particularly advantageous benefit of this change is that it flows very
well with existing Xcode workflows, namely that:
- Slicing out unused architectures is handled completely automatically
  for static builds, as an executable linking to a library with more
  architectures than it itself is linked as, the unused architectures
  will be ignored silently, resulting in the same behavior for users
  (and the App Store won't let you submit Intel architectures either).
- Removing architectures from a fat binary using lipo does NOT
  invalidate the code signature of that file or its container if it is a
  bundle. This allows shared library and framework builds of Qt to work
  mostly automatically as well, since an Xcode shell script build phase
  can remove unused architectures from the embedded frameworks when that
  is implemented, and if Qt ever starts signing its SDK releases, it
  won't interfere with that either (though binaries are just resigned).

Change-Id: I6c3578c78f75845a2fcc85f3a5b728ec997dbe90
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-09-03 09:47:56 +00:00
Jake Petroules
57378a108c Add support for Apple watchOS
Change-Id: I3f9e00569458a463af2eaa5a3a16a6afd1e9c1ea
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2016-08-19 21:05:55 +00:00
Lars Knoll
60985aa42b Use qtConfig throughout in qtbase
Use the new qtConfig macro in all pro/pri files.

This required adding some feature entries, and adding
{private,public}Feature to every referenced already existing entry.

Change-Id: I164214dad1154df6ad84e86d99ed14994ef97cf4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-08-19 04:28:05 +00:00
Liang Qi
511790fd1a Merge remote-tracking branch 'origin/5.7' into dev
Conflicts:
	config_help.txt
	configure
	mkspecs/features/uikit/sdk.prf
	src/corelib/global/qhooks.cpp
	src/corelib/io/qfilesystemwatcher.cpp
	src/corelib/io/qlockfile_unix.cpp
	src/corelib/tools/qalgorithms.h
	src/gui/kernel/qwindowsysteminterface.h
	src/gui/text/qtextdocument_p.cpp
	src/network/access/access.pri
	src/network/access/qnetworkaccessmanager.cpp
	src/network/access/qnetworkreplynsurlconnectionimpl.mm
	src/src.pro
	src/testlib/qtestcase.cpp
	src/widgets/kernel/qwidgetbackingstore_p.h
	src/widgets/styles/qwindowscestyle.cpp
	src/widgets/styles/qwindowsmobilestyle.cpp
	tests/auto/corelib/io/qdiriterator/qdiriterator.pro
	tests/auto/corelib/io/qfileinfo/qfileinfo.pro
	tests/auto/gui/kernel/qwindow/BLACKLIST
	tests/auto/widgets/dialogs/qfilesystemmodel/tst_qfilesystemmodel.cpp
	tools/configure/configureapp.cpp

Change-Id: Ibf7fb9c8cf263a810ade82f821345d0725c57c67
2016-06-13 12:46:46 +02:00
Mike Krus
03e9c6f4a6 Add support for Apple tvOS
Pass -xplatform macx-tvos-clang to configure to build.
Builds device and simulator by default.

Added ‘uikit’ platform with the common setup.
Also added QT_PLATFORM_UIKIT define (undocumented).
qmake config defines tvos (but not ios).

tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be
embedded in the binary. A new ‘bitcode’ configuration was added.
For ReleaseDevice builds (which get archived and push to the store),
bitcode is actually embedded (-fembed-bitcode passed to clang). For all
other configurations, only using bitcode markers to keep file size
down (-fembed-bitcode-marker).

Build disables Widgets in qtbase, and qtscript (unsupported,
would require fixes to JavaScriptCore source code).

Qpa same as on iOS but disables device orientation, status bar, clipboard,
menus, dialogs which are not supported on tvOS.

Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2016-05-17 16:11:23 +00:00
Mike Krus
7c7d8f870e Refactor iOS builds to facilitate tvOS port
- moved prf files to shared location (uikit, added to QMAKE_PLATFORM)
- prepare some formatting (unconditional blocks mostly) to add conditions later
- make device detection script more generic, passing filter strings
  as a parameter and returning non-os specific variables

Change-Id: I61f2b77093304ff985bec9da04fda57ff296b16b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2016-05-05 02:08:51 +00:00