This allows the developer to provide a list of languages to the manifest
by listing them in WINRT_MANIFEST.languages. It also allows setting the
default language with WINRT_MANIFEST.default_language.
Task-number: QTBUG-38557
Change-Id: I5cb94c9f45146e3068d0833b9e669dc17dca14b2
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Instead of collecting all files from the "fonts" directory to deploy
them to the phone, we only collect files which are mentioned in the
FONTS variable. Otherwise fonts that were copied to the fonts directory
earlier (due to FONTS being unset (default fonts) or set to another set
of fonts) will also be deployed as part of the project.
Change-Id: I24c77e154a9f2ec75e88d487c056b0be46e17e87
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
WinRT distinguishes between regular capabilities and device
capabilities. For now the latter section are location, microphone,
proximity and webcam. Hence we must add those properly to the generated
manifest.
However, Windows Phone currently combines all of these into the
Capability section, so add a warning if someone uses devicecapabilities
for Windows Phone.
Task-number: QTBUG-37932
Change-Id: I8e9550f29b6afdea3737cc85bdc68344fc04223d
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
For Visual Studio we can add the fonts we want to deploy to the
project file by using the DEPLOYMENT variable.
Change-Id: Ifc87a12a2bb4ec4ff1c0a8dc8f0b1fbf37e4e513
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Visual Studio does not like empty dependencies block in manifest XML.
At least my Visual Studio 2013 fails to open visual manifest editor for
XML containing the following block:
<Dependencies>
</Dependencies>
If the block is removed or if the block has one or more PackageDependency
entries the editor accepts it.
Moved the <Dependencies> block to prf, so that it is only written when
project really has dependencies. Also <Capabilities> block is moved to prf
for consistency. On Windows Phone, where the <Capabilities> block is
required, it is kept in the output even if it is empty.
Change-Id: I531180d0081e4612f75be54f3813831857f1ed43
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
QMake always places makefiles, including vcproj files, to OUT_PWD.
BUILD_DIR i.e. QMAKE_RESOLVED_TARGET refers to location where target
is generated. If TARGET is specified in pro file with path, such as:
TARGET = ../../debug/tst_qlocale
The QMAKE_RESOLVED_TARGET refers to that path, and it differs from OUT_PWD.
Because Visual Studio requires a design-mode manifest in the same location
as the vcproj, resolved BUILD_DIR separately based on TEMPLATE.
Change-Id: I8dbaa862a5f53ac168f4643c17baabd7b4f0287d
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
This feature (package_manifest) generates a basic application manifest
from a template provided by the mkspec or the developer. It is meant to
deliver an out-of-the-box build experience without attempting to
exhaustively cover all manifest options. It is meant to be a starting
point which allows the developer to customize the manifest further. It
also becomes the default package manifest generator for Windows Phone,
replacing autogen_wmappmanifest.
Common variables, such as the target executable, are populated by qmake
in the newly created manifest. Default icons are also created if needed,
as the build will fail without them. The input manifest can be set by
assigning a file name to WINRT_MANIFEST. Additional options are
documented in the .prf file. If an existing (non-generated) manifest is
already in the directory, it will not be overwritten.
Task-number: QTBUG-35328
Change-Id: I57576a17ff9d2b564c0828f815949cb26d276bfd
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Compared to other platforms there is no concept of a console
application in WinRT. Hence all applications need to be UI
applications and use winmain.
Furthermore winmain takes care of launch arguments to be
properly converted to arguments passed to user's main().
There is a chicken and egg problem with config.tests as
compilation needs to have an existing entry point which is not
available at configure time.
Hence hardcode the entry point to main for configuring to WinRT.
Those tests are pure compile tests, so the logic of the test
does not change.
Change-Id: I4d3186691a8440845c24b2529cc9646e86dfd8da
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
