View source for Qt-contributors-summit-2014-QtCS14CrossPlatformManifestXmlInfoPlist

=Cross-platform Manifest.xml / Info.plist=

The goal is to have a common place to put information related to the application Info.plist/mainfest.xml, icon, orientation,… so that normally one can set it once for all platform.<br /> Platform specific specialization should be possible.

A proposal was to use a command line tool that would have -platform xyz as argument, and it would look for a AppInfoXyz.qml if present and fall back to AppInfoBase.qml file.

The file would look like this:

Qml is already used in qt, and we already have good support for editing it (adding completions,…) but there were two important drawbacks highlighted:

1. Bootstrapping problems: it needs Qt on the host to be used<br /> 2. Too powerful: chance of misuse, and unmantainability

Still it was deemed ok for prototyping, so the content were discussed:

I was thought that it is better to begin with few properties and add them as requests come in.

For apple a reference of the keys for iOS is

https://developer.apple.com/library/ios/documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html

The predefined winrt app manifest options are defined as qmake variables, and are listed here: http://doc.qt.io/qt-5/qmake-variable-reference.html#winrt-manifest

One could think to also add support for app store properties:<br />

but this was skipped for now

==Issues==

===Why not just unify the variables already supported by the existing qmake features?===

* We want to support other build tools (CMake, qbs). <span class="caps">OTOH</span>, simple template variable replacement could be built into those tools as well.

===How can we have a new build tool that relies on <span class="caps">QML</span>?===

* Build this feature into qbs and only support this feature when using qbs
* Use <span class="caps">JSON</span> instead of <span class="caps">QML</span> (the Qt <span class="caps">JSON</span> classes are bootstrapped)

===How do we add aribitrary values which show up in the manifest?===

Like in the qmake variable approach, it would be good to make this flexible enough that arbitrary values can be added for variable replacement (this works easily for <span class="caps">QML</span>, simply add more properties). The proposal above has an arbitraryValues property, but a JavaScript object literal is less <span class="caps">QML</span>-esque than a list of properties. This way, we aren’t limited by the values in the base class or in need of an “arbitraryValues” property to catch everything.

===How will we make the manifest generation flexible and avoid lots of code bloat in the generation tool?===

We can use variable replacement (and perhaps a special syntax for loops) of a loose file template like used in qmake substitutes. That way, the tool itself doesn’t have hard-coded template parts that it generates from C++. If most manifests are <span class="caps">XML</span>-based, it might be worth supporting <span class="caps">XSLT</span> to perform more advanced variable replacement and transforms.