summaryrefslogtreecommitdiffstats
path: root/doc/src/development/qmake-manual.qdoc
diff options
context:
space:
mode:
authorVolker Hilsheimer <volker.hilsheimer@nokia.com>2009-08-17 16:37:42 (GMT)
committerVolker Hilsheimer <volker.hilsheimer@nokia.com>2009-08-17 16:37:42 (GMT)
commit911557fcf7dedc002e689a0d66efd2b77e044bd1 (patch)
treea66138f008c27f39e5306dc6f2df01c129e11988 /doc/src/development/qmake-manual.qdoc
parent285d4b12cb937a5672d6eb15781f03d249f8cfc1 (diff)
downloadQt-911557fcf7dedc002e689a0d66efd2b77e044bd1.zip
Qt-911557fcf7dedc002e689a0d66efd2b77e044bd1.tar.gz
Qt-911557fcf7dedc002e689a0d66efd2b77e044bd1.tar.bz2
Restructure the documentation, both on a file and on a content level.
- directory structure in doc/src - moving of class-specific documentation together with classes - new, less cluttered index page - significantely reduced number of "groups of classes" - categorized all (?) documentation into "Frameworks" or "Howtos" - reformatting of examples pages - splitting of very long documentation pages into walkthroughs - some writing where it was missing Squashed commit of the following: commit b44ea6c917a7470a678509f4c6c9b8836d277346 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 18:32:09 2009 +0200 Some cleaning up in the categories. commit b592c6eba72332fd23911251d836cf0af4514bae Merge: 1e10d9e 285d4b1 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 18:20:57 2009 +0200 Merge branch 'master' into doccleanup commit 1e10d9e732f4171e61b3d1ecf0b64f7509e71607 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 18:19:03 2009 +0200 Split the "io" group into "io" and "network". And list the network classes in the respective overview documentation. commit fae86d24becb69c532a9c3b4fbf744c44a54f49d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 18:00:32 2009 +0200 Move the string-processing classes together with the Unicode in Qt docu. commit d2a6dd3307b0306bd7a8e283e11a99e833206963 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 18:00:14 2009 +0200 Not a toplevel topic, it's within the "paint system" set of pages. commit 44cba00cdf7fb086dd3bb62b15c0f9a7915e20c2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 17:57:37 2009 +0200 "Canvas UI" is not a stand-alone concept in Qt - yet! commit 5f6e69b38fbca661709bc20b502ab0bc1b251b96 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 17:43:01 2009 +0200 Can just as well delete the old index. commit aa5ec5327dceb1d3df62b990a32c970cce03ba9c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 17:39:52 2009 +0200 Some rephrasing and easier access to the "Keyboard Focus" docu. commit 6248de281565cafce12221c902e9944867b338b3 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 17:37:02 2009 +0200 Replace the old index with the new index. commit 110acab8af0c99db9905b0f4cc6e93c325b1e3c6 Merge: d88d526 53807e5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 17 16:04:59 2009 +0200 Merge branch 'master' into doccleanup commit d88d52681d758e9e730de0e69290472728bf8c40 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 16 17:34:14 2009 +0200 Give the "Widgets and Layouts" topic a bit more content. commit 01e108a5f2d1d0948c2093987a77f222d6cc4d09 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 16 14:21:41 2009 +0200 Move OpenVG "best practices" documentation into howtos directory. commit 86f4ca38f965909a29cee0478c537558a4ea8f5a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 16 14:18:32 2009 +0200 Add module documentation for OpenVG and Multimedia. commit 9fef923acbbb75cdc3fc4e984aec177ddcd24c53 Merge: e7e5cd9 72c1cb2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 16 13:20:23 2009 +0200 Merge branch 'master' into doccleanup commit e7e5cd9444ac0e7be55ecfbeb8c9ace23784205b Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 16 13:20:08 2009 +0200 Add Google custom search box. Not sure why that change was never merged in by git. commit 348372947a3d7da2b28325731ac02bbc67cdec41 Merge: 3ff51b9 aa09d4f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 15 02:14:31 2009 +0200 Merge branch 'master' into doccleanup commit 3ff51b9b52af39c00a938db380809e36b6c701c9 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 15 02:09:38 2009 +0200 Minor word-smithing. commit da612b4130061e094a16d47a450f3f3fe6f547c7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 15 01:55:16 2009 +0200 Separating the "multimedia" group into reasonable sets of classes. commit 838955a1a780e41ea77676e1bef8e471c7a2a2f5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 23:12:33 2009 +0200 Just one file, doesn't need a separate directory. commit b99f56262faa4410880d08787f2c8d9a509d303d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 23:05:59 2009 +0200 Move documentation for Asian codecs into src/corelib/codecs. Not ideal, the source of most of those codecs live in src/plugins/codecs, but since this is no real API documentation it's probably appropriate. commit ba2258c0b6587d959cdfe6ff99c4d36319077aac Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 22:24:33 2009 +0200 Renaming of files that used old product/company names. commit 30ee7deb935bb3de4257cd71be5ba9610376047c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 22:14:30 2009 +0200 Those will only used by "Qt 4 for Qt 3" users, so leave the original text. commit d0c110d047bbbd2dde70fc51ad702db59fa3883b Merge: c5eccd5 8198d35 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 22:12:15 2009 +0200 Merge branch 'master' into doccleanup commit c5eccd51ad85cfaf07ea8522a977b7bef70f70fd Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 22:09:43 2009 +0200 Moving some last files from doc/src into subdirectories. commit d2dc303d92c1f66bf721b65fca1c6d55ab7ec01d Merge: 0bdf16e a835ec7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 15:39:59 2009 +0200 Merge branch 'master' into doccleanup commit 0bdf16e1bb04e532d4cc72c5646cb28470d5e627 Merge: 04bb351 c73fd72 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 14 13:08:37 2009 +0200 Merge branch 'master' into doccleanup Conflicts: src/3rdparty/webkit/WebKit/qt/Api/qwebelement.cpp commit 04bb3513f107a895cfbbf98f8c4f9a67e392c72a Merge: 8a52ce8 07d2ce1 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 12 19:58:04 2009 +0200 Merge branch 'master' into doccleanup Conflicts: tools/qdoc3/test/qt-html-templates.qdocconf commit 8a52ce8055d5d8b1bf799bf1fdde18aaf8b940c7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 12 13:30:50 2009 +0200 Fix some links to the qt.nokia.com page, and at least some linking to IO. commit f7823801bf750b0b76ce0871c3f9e8e59c7901fe Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 12 12:27:19 2009 +0200 Make links in header point to the pages with links to everything else. commit 335012b7e96698d6ec7994fdfd52813140f12413 Merge: 21b1263 96b6a3c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 12 12:17:57 2009 +0200 Merge branch 'master' into doccleanup Conflicts: doc/src/classes/qtdesigner-api.qdoc doc/src/desktop-integration.qdoc doc/src/distributingqt.qdoc doc/src/examples-overview.qdoc doc/src/examples.qdoc doc/src/frameworks-technologies/dbus-adaptors.qdoc doc/src/geometry.qdoc doc/src/groups.qdoc doc/src/objecttrees.qdoc doc/src/plugins-howto.qdoc doc/src/qt4-accessibility.qdoc doc/src/qt4-scribe.qdoc doc/src/qt4-sql.qdoc doc/src/qt4-styles.qdoc doc/src/qtdbus.qdoc doc/src/qtgui.qdoc doc/src/qtmain.qdoc doc/src/qtopengl.qdoc doc/src/qtscripttools.qdoc doc/src/qtsvg.qdoc doc/src/qtuiloader.qdoc doc/src/qundo.qdoc doc/src/richtext.qdoc doc/src/topics.qdoc doc/src/xml-processing/xml-processing.qdoc commit 21b126346989a86a828ee8a66bb12108d2bb2b71 Merge: 88e7d76 204c771 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 11 18:15:17 2009 +0200 Merge branch 'master' into doccleanup commit 88e7d76ceec664404a913469025ed9a7ca6f4fb0 Merge: 97c4128 1c62dc4 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 11 18:00:56 2009 +0200 Merge branch 'master' into doccleanup commit 97c412815162859d853c5a4ede1eb9bd4be4af9b Merge: cf5d8ae 4096911 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 19:27:08 2009 +0200 Merge branch 'master' into doccleanup commit cf5d8ae4b09a92fed5b4e4cabbcfd49116e9e13f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 19:09:57 2009 +0200 This should link to the platform specific documentation. commit 38610f0ff210286f92528495d48f434d2c0db8e8 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 18:59:35 2009 +0200 These groups are embedded in the respective framework overview already. commit 1e58a90c561d33aada9427b17db8e0f7bbe02fa7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 18:54:47 2009 +0200 Remove howtos and overviews from script group. The "Making Applications Scriptable" page needs to be split into a walkthrough anyway. commit 1e68b8d7d53500b8fb6c9c821d46e045ed7efe6f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 18:30:10 2009 +0200 Groups are for classes. The objectmodel framework overview links to those. commit a0a95420c82e2a77150b070e98609aa3e1b3b1a6 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 18:22:20 2009 +0200 Kill the "buildsystem" group. All documents can be reached through the "Developing with Qt" page. commit 7b23a40c5ba3a215fba6032ad96199b5c9797e98 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 18:07:23 2009 +0200 This guide should only be in the porting group. commit ef731bcc53a9b34ba3b42e5ad7caf4234941c4a9 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 18:06:21 2009 +0200 Phonon is a framework on its own. The whole "multimedia" group is a rather random collection of stuff... commit 5d290d48fc428573ccd31861cf57d214051ba349 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 17:59:36 2009 +0200 Move the Qt Help documentation into frameworks. This needs a bit of a rewrite, and the list of classes needs to be integrated. commit 5e4d094c8712bfb46d844e09746aad5da3ac4a91 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 17:58:52 2009 +0200 The list of all classes that use implicit sharing is not useful on its own. commit 2059a0be23c5953f9758098cb7a9416cb86d5ad1 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 17:55:20 2009 +0200 Make the QtScript overview documentation part of frameworks. commit 3413696bd745ee5862aa517dcfc9c8446fee9b82 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 17:54:59 2009 +0200 Make the list of drag & drop classes part of the framework docu. commit f1c85ea263b30de1e1a1f6c5cb8b8d9ee12254cb Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 17:44:57 2009 +0200 Porting guides are part of the Howto's commit cfcc742f938cf7c278f1f8b11b24a61f62fb4c62 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 17:44:26 2009 +0200 All platform specific docu is available through one toplevel page. commit 53c642fe4cbc2dbd44fe5b9b4e32feeca438b5c3 Merge: c564285 41537bb Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 16:48:09 2009 +0200 Merge branch 'master' into doccleanup commit c5642857b2f2364134f58776661cc08a9da13b2c Merge: 9cdeba7 24aa363 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 10 15:53:47 2009 +0200 Merge branch 'master' into doccleanup commit 9cdeba712c51eb0bf71eab35080734a2b93efcc5 Merge: 09dac33 d13418e Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 8 11:46:42 2009 +0200 Merge branch 'master' into doccleanup commit 09dac333d427792a8d33fa311a63c620678e7920 Merge: f7b211e dfa2842 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Aug 7 15:40:33 2009 +0200 Merge branch 'master' into doccleanup Conflicts: doc/src/examples.qdoc commit f7b211e5588fee20913a8d02c55cca0e05ea2859 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 14:58:49 2009 +0200 Rename file to follow naming scheme and resulting html. commit ed6432fea376e60e4dd7c8987ed61a063af11ac7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 14:58:10 2009 +0200 Structure the XML documentation into a walk-through. The XmlPatterns docu should probably be split into two or three sections, XQuery, XPath and XML Schema. commit 3dbc1d4ca08d3cac47ca2709b6fb1a2419442c36 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 14:15:00 2009 +0200 Add a table of contents. commit 1569c35cb90c10ead72dcea2c4b99a0a6cbfcc13 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 14:04:52 2009 +0200 Splitting the long SQL documentation into walkthrough steps. commit 6a05688bce3cca34dd1b8b323b8feb49d3133d7e Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 13:49:50 2009 +0200 Combining various desktop integration topics into one document. commit c02c9adca98ba1d4494dd9c7de4ef5b191d9721a Merge: 4cc4a81 2a286b0 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 08:16:04 2009 +0200 Merge branch 'doccleanup' of git@scm.dev.nokia.troll.no:qt/vohis-docuwork into doccleanup commit 4cc4a81324cff3c1ad91867cf3acb87d9b4184c6 Merge: a88dc5d 06d57fc Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Aug 6 08:15:52 2009 +0200 Merge branch 'master' into doccleanup commit 2a286b03167ce028821b4007bf08537d2c5637c2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 23:23:28 2009 +0200 Some writing on windows and dialogs. Also some restructuring of the existing content. commit a88dc5d72bec7abeec23b289c212418499c25e4a Merge: 86f956c fb8bb14 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 18:09:58 2009 +0200 Merge branch 'master' into doccleanup commit 86f956c89b9b8fb3d684665797d4a5b5e538fb2c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 17:09:36 2009 +0200 All "Qt 4 vs Qt 3" docu lives in porting. Some of those files have been changed by now to move docu into overview files where the respective information was missing. commit ac6f1fc8b1e760ae69ce799e13ac92144eeb89e2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 17:06:15 2009 +0200 Start work on windows and dialogs docu. commit 4253dea2661dc3526a9dec53f336301992b543cb Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 16:03:52 2009 +0200 Make QtWebKit module documentation follow the other modules: - Module overview only lists classes, library, header and license implication - Usage-documentation is separated commit a27f1b8498ba8d06743e70ecde4fc1e44d5f02f0 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 16:01:25 2009 +0200 Make QtWebKit classes show up in the module overview. commit d38d185ec8b7d32037e86b4ecbbc725343aabea7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 15:40:17 2009 +0200 Make the most important sections a bit larger. commit 70991dcdfb8c00baa960381b297fdcb8ed7f50d0 Merge: deb4c2b e95166d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 14:35:07 2009 +0200 Merge branch 'master' into doccleanup commit deb4c2bb4d7120579fda541b03c0a77d989089d5 Merge: 37e5373 f78bd88 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 12:59:22 2009 +0200 Merge branch 'master' into doccleanup commit 37e5373dcc5455b1e029ee389ce7985a98f579d9 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 11:32:43 2009 +0200 These new examples are not yet fully documented commit 85fb40ea11458040e09302bb898d89664eb280b5 Merge: 8b78e18 bcf41cf Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 11:30:26 2009 +0200 Merge branch 'master' into doccleanup Conflicts: doc/src/examples-overview.qdoc doc/src/examples.qdoc tools/qdoc3/htmlgenerator.cpp commit 8b78e1828b93a9762301d80cb110a1f1b7c4211f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 00:04:36 2009 +0200 Line-feed fixes. commit 2fa80a411dd96369c0e09defc54af44118930ae5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 00:04:00 2009 +0200 The "buildsystem" docu seems a reasonable start for proper documentation. Three lists of tools - in the buildsystem table, in the tools-list docu and implicitly through \ingroup qttools. Needs to be consolidated. commit 8d4043feab66698664cfa17bd150eabf4fe2420d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 00:01:32 2009 +0200 Restructure the i18n page. The list of classes needs to be reviewed. commit 49f718b1e75c02bc43feac93d5b233064c032555 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Wed Aug 5 00:00:45 2009 +0200 The Accessibility group is just a group of classes. commit b17db7dc54c1945cd2651fdebde471c71ef4001d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 23:40:21 2009 +0200 Remove the "Topics" group. Things are part of frameworks or how-to documentation. Top-level groups are right now still on the "all overviews" document. commit 31e5c276b50130542dbd824b0b8cc20b16ca1cb1 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 22:45:43 2009 +0200 Splitting the thread documentation into multiple pages. Also add relevant classes from QtConcurrent to the thread group. commit d491ffb0e949f1d8653d73495e091b241a025558 Merge: e99794c 3ff7afd Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 19:29:18 2009 +0200 Merge branch 'doccleanup' of git@scm.dev.nokia.troll.no:qt/vohis-docuwork into doccleanup commit 3ff7afd6c11d824af38c72afdea4b6578f6de784 Merge: 1dae0ad 2df403d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 18:07:11 2009 +0200 Merge branch 'doccleanup' of git@scm.dev.nokia.troll.no:qt/vohis-docuwork into doccleanup Conflicts: doc/src/accessible.qdoc doc/src/activeqt.qdoc doc/src/animation.qdoc doc/src/containers.qdoc doc/src/custom-types.qdoc doc/src/desktop-integration.qdoc doc/src/dnd.qdoc doc/src/frameworks-technologies/accessible.qdoc doc/src/frameworks-technologies/activeqt-container.qdoc doc/src/frameworks-technologies/activeqt-server.qdoc doc/src/frameworks-technologies/activeqt.qdoc doc/src/frameworks-technologies/animation.qdoc doc/src/frameworks-technologies/containers.qdoc doc/src/frameworks-technologies/dbus-adaptors.qdoc doc/src/frameworks-technologies/dbus-intro.qdoc doc/src/frameworks-technologies/desktop-integration.qdoc doc/src/frameworks-technologies/dnd.qdoc doc/src/frameworks-technologies/implicit-sharing.qdoc doc/src/frameworks-technologies/ipc.qdoc doc/src/frameworks-technologies/model-view-programming.qdoc doc/src/frameworks-technologies/phonon.qdoc doc/src/frameworks-technologies/qt4-interview.qdoc doc/src/frameworks-technologies/qtdesigner.qdoc doc/src/frameworks-technologies/qthelp.qdoc doc/src/frameworks-technologies/statemachine.qdoc doc/src/frameworks-technologies/templates.qdoc doc/src/frameworks-technologies/unicode.qdoc doc/src/frameworks/accessible.qdoc doc/src/frameworks/activeqt-container.qdoc doc/src/frameworks/activeqt-server.qdoc doc/src/frameworks/activeqt.qdoc doc/src/frameworks/animation.qdoc doc/src/frameworks/containers.qdoc doc/src/frameworks/dbus-adaptors.qdoc doc/src/frameworks/dbus-intro.qdoc doc/src/frameworks/desktop-integration.qdoc doc/src/frameworks/dnd.qdoc doc/src/frameworks/ipc.qdoc doc/src/frameworks/model-view-programming.qdoc doc/src/frameworks/phonon.qdoc doc/src/frameworks/qt4-interview.qdoc doc/src/frameworks/qtdesigner.qdoc doc/src/frameworks/qthelp.qdoc doc/src/frameworks/qundo.qdoc doc/src/frameworks/richtext.qdoc doc/src/frameworks/statemachine.qdoc doc/src/graphicsview.qdoc doc/src/howtos/custom-types.qdoc doc/src/howtos/session.qdoc doc/src/implicit-sharing.qdoc doc/src/introtodbus.qdoc doc/src/ipc.qdoc doc/src/model-view-programming.qdoc doc/src/modules.qdoc doc/src/new_index.qdoc doc/src/objectmodel/custom-types.qdoc doc/src/objectmodel/object.qdoc doc/src/objectmodel/objecttrees.qdoc doc/src/overviews.qdoc doc/src/phonon.qdoc doc/src/porting/qt4-tulip.qdoc doc/src/qaxcontainer.qdoc doc/src/qaxserver.qdoc doc/src/qdbusadaptors.qdoc doc/src/qt4-interview.qdoc doc/src/qtdesigner.qdoc doc/src/qthelp.qdoc doc/src/statemachine.qdoc doc/src/technologies/implicit-sharing.qdoc doc/src/technologies/templates.qdoc doc/src/technologies/unicode.qdoc doc/src/templates.qdoc doc/src/unicode.qdoc doc/src/widgets-and-layouts/layout.qdoc doc/src/widgets-and-layouts/styles.qdoc doc/src/widgets-and-layouts/widgets.qdoc src/gui/kernel/qstandardgestures.cpp commit 1dae0adf3d85620f7574a2a0475510a627a896dc Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:46:58 2009 +0200 This way it appears as part of the overview, and the moc docu links to it. commit 5802092887e46dc5eb034bb9b45dd34a265607f5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:45:09 2009 +0200 Not sure what it is yet, but definitely not an architecture. QDataStream links to this page, that might just as well be enough. commit 69d32c4ff079bcaea098b34de70b7d9587e51e88 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:43:42 2009 +0200 Use \annotatedlist command to list all widget classes. Needs nicer formatting, ie qdoc could be \table aware for those lists and skip the header. commit 02057d7575bb4f0875e82ea4cb76552f2d8ac17a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:35:46 2009 +0200 This should be together with all the other licensing documentation. commit be91b2fe15c67cb90eaa59121d7ff51eb21b4dba Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:26:02 2009 +0200 These are best practices. commit 8e0b104db1266a736ac246c9466656c058df18f2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:25:35 2009 +0200 Another technology. commit 19c16384d712c652716776c94c749030b0742752 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:24:55 2009 +0200 Remove duplicate and out-of-date license headers. commit 689aa91de0f840fc0f98f0adfbb2f18d72c6b985 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 17:21:00 2009 +0200 Move into frameworks. Add explicitly printed list of classes instead of using a separate \group page. The \group page is still there as long as qdoc requires it. Threading and WebKit are still "architectures", coming later. commit 3f96833ab78dacd7ae66e6dd58a3a0dee22229e7 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 16:35:17 2009 +0200 Remove IPC group. Only two classes, and those are explicitly listed in the real documentation about IPC in Qt. commit bbb02d8cc55c9595226f42fe5b617261584c6bdd Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 15:54:46 2009 +0200 Use the new \annotatedlist command, and make it a framework. commit ba3a0376acb44ae5cafc8bd3802bd425dcb663a5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 15:38:24 2009 +0200 Make \annotatedlist <group> work. commit c80fb8d6a143c81700c2aefe7af1e83dd487dde4 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 15:37:51 2009 +0200 These are API documentation, not architecture. commit 713744520bd35d510864ad48464575f1c8a35668 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 15:10:25 2009 +0200 Frameworks and technologies used in Qt are really one thing. commit a86d4248c1e3c13f245c49f3f2d018ec4babc822 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 15:00:35 2009 +0200 Move into correct groups and make the howto a walk-through. commit 7cc88f310e0dfa37d39026d67443f518531d7fe9 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 12:50:58 2009 +0200 Architecture -> Frameworks and Technologies commit 4a3ba3f19d78c4df5343af951c761df47e22759a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 12:50:41 2009 +0200 Some consolidation of the Tulip documentation. commit d3dab98b96d83ce408523f8ccb9363a09eed1f34 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 12:01:10 2009 +0200 Start with "Frameworks and Technologies" vs "howtos and best practices". commit 37a8e364442e6234c6a83667eb64af1c79b38e9b Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 12:00:34 2009 +0200 Beautify. commit c86d844a79406d4b9fee67578efd67e27ce96b83 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 00:04:40 2009 +0200 Fix some headers. commit 20b775d781d3b1d91164320807c21c8a6efcf011 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 23:48:17 2009 +0200 Split the accessibility docu into a "compared to Qt 3" section, and move real information into the overview. commit 6846a1bccf7d212f7ee0471f992cfb16efb71c43 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 23:47:37 2009 +0200 The gui-programming seems rather arbitrary and should go away. Some things fit into the desktop integration, which is probably more a howto. Focus is a concept in the widgets context, and application-wide techniques like accelerators should probably be part of the "window" docu. commit 8c7bc99e78a69751080de07618bf003bc227e2db Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 23:45:28 2009 +0200 Move "Getting Started" documentation into getting-started directory. commit 561cc3eafa20903243f3946ac4b7b724554c341c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 19:06:16 2009 +0200 Group "getting started" documents into a walkthrough structure. commit 6d703807348923a068dea7360fb4456cbde071b6 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 17:35:15 2009 +0200 Add screenshots for example-overview page. commit f7a47536305e157c16e8a863f145a2617606a2cc Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 2 16:57:04 2009 +0200 Link to the real documentation, not just to the modules overview. commit 92ce250ba206f4dde198637f1a30cd10768d9ae5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 2 16:56:41 2009 +0200 A new layout for the examples. Needs a bit of shuffeling around, and more screenshots and descriptive text for some categories. commit a5e2e2939b32dee0aceabe136aa4c13b12c88070 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 22:39:27 2009 +0200 Cleanup the script-related groups a bit. commit ca469165a9f55ca6bd31e53d85d74883fe892ed4 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 22:17:16 2009 +0200 Add QContiguousCache to the list of containers as a special case. commit a21292704bd12daf2495195b216424442e097220 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 21:52:37 2009 +0200 Cleaning up groups of text- and string-related classes. Make a clear separation between classes that deal with string data (ie QString, QByteArray, QTextStream) and classes that are part of the "scribe" framework. Merge documentation from the Qt 4.0 introduction of Scribe into the richtext processing guide. commit 3854592806e23955f69613bdc1e2998d5d6f3a8a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 20:50:06 2009 +0200 One group of thread-related classes should be enough. commit b8935bc0ec3d33b6a3fe7b3b220b5781ad79d68d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 19:32:21 2009 +0200 Move documentation for classes into same directory as the respective header files (or implementation file, if one exists). This follows the Qt standard, and there is no particular reason why .qdoc files cannot live in src. Since there are a number of .cpp files that have only documentation it might also be an idea to rename the .qdoc files to .cpp and add them to the .pro-files to have them included in generated project files for easier access. commit b61cc5eaf2f2bf72cff209ab0f69fde48fb87471 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 19:29:46 2009 +0200 Starting to tie together the widgets and layouts groups and documentation. commit 47fb0c6cf1dacdbfa07a59cf4dc703dd2c35eb8c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 18:43:34 2009 +0200 This is all duplicate information that is better covered in the sql-programming guide. commit d3c70dd9ed84b4688cbabf30f6b906665b676b76 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 18:37:53 2009 +0200 Consolidate style documentation. commit 1d8d30eee1e2fe9f8e77ce1462803921b2132ade Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 17:13:44 2009 +0200 Split plugin-documentation into two: writing plugins and deploying plugins. commit a329665353a78749b0d4fdd6e75403252d34f679 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 14:19:47 2009 +0200 Some final module cleaning up. commit e3de6579d43cc9796b69188cfb9d3d415a91a770 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:51:54 2009 +0200 Move remaining overview groups into one file. commit 7d783342f520f8376e561246268371d0b74a4e44 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:51:34 2009 +0200 The "io" group should be about file access (be it local or networked). commit 961fcefb034fea89d1aab2bfed5acaabb65e8d34 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:36:51 2009 +0200 Kill the "time" group. The "How to use timers in your application" documentation covers the usecase. commit c7bebf1a4c3e2da54ce6a5d649926d76bf65e41e Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:28:21 2009 +0200 Kill the group "misc". commit e414a8945cb938ccc6bd1bd8cd52adbfade096c2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:09:24 2009 +0200 Kill the "Environment" group. It was a random collection of classes, mostly ending up in there because of copy/paste (I suspect). commit 9236a04e7ac6dd3910f035d15b8ab23297fd5f24 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:08:37 2009 +0200 More moving of files and content. commit 1ef3134bade2df33ff68c7c906cf20343abd86a5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 02:03:07 2009 +0200 Workaround qdoc being difficult. commit 49064b0570088fe749fc08c02c5ab6d23855089f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 01:49:52 2009 +0200 Some more moving of files into meaningful directories. commit df4ced831cf9f49c638c231fa9f2754699a8a59d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 01:41:14 2009 +0200 Separate module documentation from frameworks documentation. Module documentation will list the classes in each module, how to use the respective libraries and headerfiles from a build-system perspective and what the legal implications are when linking against those libraries. The documentation of frameworks lives now in the frameworks subdirectory, or in dedicated subdirectories for the key frameworks. commit f4ccabe1abb97f91f196dab1948fee6135c9fa6e Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 00:47:54 2009 +0200 Group files in subdirectories that would correspond to top level topics. commit ceb0110a364185b8b5d7bea3d3d1d54500035fcc Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 21:48:45 2009 +0200 Group files in subdirectories that would correspond to top level topics. commit 72a4dae65b25c9df400218252f1c68d59724ff75 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 20:57:39 2009 +0200 Fix a few links. commit ecb79681417e8bc3d8e46065dc12146f4d4dfc5f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 20:20:55 2009 +0200 Consolidate the two example documents into one page. commit d30d980055e7c531c9e73cdf9a1b220ce9691eef Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 19:25:16 2009 +0200 The QtAssistant module is obsolete, remove it. QAssistantClient is in the list of obsolete classes. commit 137ecd1ee70f0766fd94c6199d8a6b8217d020ca Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 18:56:14 2009 +0200 Get rid of \mainclass If we want to select a list of main classes, then we can use \ingroup for that, and document them coherently as part of the Fundamentals or a relevant framework. commit 042a7f21e68120e43b68444cbf3cfeca3aad4488 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 18:23:55 2009 +0200 The new index page and respective style changes. commit 5245d784eb46287f8e1ae41addb2765eb19b0663 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 17:05:46 2009 +0200 Deployment group is gone. commit 567d737a8d08f227133674ebfe2d161888862b8c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 16:48:53 2009 +0200 All "lists of classes etc" are now in classes.qdoc... I hope. commit 0bb6074c0b38f07697e72a50a2ef60b561e718fe Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 16:47:20 2009 +0200 Cleaning up files documenting deployment. Text need to be reviewed and merged. commit 2df403da24a2959c02d0d845d1d4fac0c3aa38e0 Author: Thierry Bastian <thierry.bastian@nokia.com> Date: Mon Aug 3 16:49:46 2009 +0200 fix warnings on mingw (gcc4.4) basically reordering members initialization in constructors or fixing singed/unsigned checks. Reviewed-by: Trustme commit e887c7705b8b7f218b3605eeefb316dea274fe27 Author: Richard Moe Gustavsen <richard.gustavsen@nokia.com> Date: Tue Aug 4 10:00:01 2009 +0200 Mac: Remove debug work output commit 62687960508b2855b48d64825b445e5738c44142 Author: Richard Moe Gustavsen <richard.gustavsen@nokia.com> Date: Tue Aug 4 09:45:47 2009 +0200 Modify imagewidget example so it works with new API commit 9c7aed68270b336ae9a309d9eb0107d49729c1f3 Author: Richard Moe Gustavsen <richard.gustavsen@nokia.com> Date: Tue Aug 4 09:43:14 2009 +0200 Add support for pan gesture on mac (carbon and cocoa) commit be5783878a977148b34dc64c464e951be312964e Author: Morten Sorvig <msorvig@trolltech.com> Date: Tue Aug 4 09:47:05 2009 +0200 Remove the "preliminary support" warning for 10.6 Also make the "usupported on > 10.6" error a warning. No need to stop the build, the warning will be printed enough times. commit f6282eec434d073fef46d50ef141df6fa36033b9 Author: Morten Sorvig <msorvig@trolltech.com> Date: Tue Aug 4 09:31:56 2009 +0200 Build on snow leopard. Don't error out when building qmake, just let it build a 64-bit binary (even for carbon) RebBy: Richard Moe Gustavsen commit abae82a26f4dec34635827acf0784058be638e31 Author: Morten Sorvig <msorvig@trolltech.com> Date: Tue Aug 4 08:15:21 2009 +0200 Make Cocoa builds 64-bit by default on snow leopard. commit 4672e771c164503d998ccb6ca05cf7e7906fb031 Author: Jason McDonald <jason.mcdonald@nokia.com> Date: Tue Aug 4 15:40:15 2009 +1000 Fix incorrect license headers. Reviewed-by: Trust Me commit a3bd65e8eb0fd39e14539919cc9ced645c969883 Author: Bill King <bill.king@nokia.com> Date: Tue Aug 4 14:57:36 2009 +1000 Fixes failed queries when mysql auto-prepares Queries like "Show Index" etc, fail on mysql when automatically prepared due to a bug in several versions of mysql. Basically anything but a select query will fail. This fixes this by making the user explicitly prepare the query if they want to, and the blame then falls on them if they try and prepare a statement likely to fail. This fix also seems to result in a speedup for single-execution queries, possibly due to reduction in roundtrip communications. All autotests pass & behaviour conforms to documentation. Task-number: 252450, 246125 commit 4612596a6a945ab0199fe06727ff3ea350092ec1 Author: Jason McDonald <jason.mcdonald@nokia.com> Date: Tue Aug 4 14:49:14 2009 +1000 Fix obsolete license headers Reviewed-by: Trust Me commit c3bcc8b094341e0dc768ef5820ba359e2c23436a Author: Aaron Kennedy <aaron.kennedy@nokia.com> Date: Tue Aug 4 10:59:02 2009 +1000 Doc fixes Reviewed-by: TrustMe commit 1d60528ced1f6818a60889d672089bfe4d2290bb Author: Morten Sorvig <msorvig@trolltech.com> Date: Mon Aug 3 15:57:44 2009 +0200 Fix spelling error. commit e99794c1200515f18ffdd0bec9c143db46e009a1 Merge: 199db81 d65f893 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 09:24:14 2009 +0200 Merge branch 'master' into doccleanup commit 199db8104a680f91451cf2c93d2d41077b5605bb Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Tue Aug 4 00:04:40 2009 +0200 Fix some headers. commit e8f8193b951a9f9e4b6d309c44151c47b715e901 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 23:48:17 2009 +0200 Split the accessibility docu into a "compared to Qt 3" section, and move real information into the overview. commit 8006ec36024e972be21e8397c2cc758a0e9b2ba0 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 23:47:37 2009 +0200 The gui-programming seems rather arbitrary and should go away. Some things fit into the desktop integration, which is probably more a howto. Focus is a concept in the widgets context, and application-wide techniques like accelerators should probably be part of the "window" docu. commit 8dab96460280b8af6726905e8d5d24020930b882 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 23:45:28 2009 +0200 Move "Getting Started" documentation into getting-started directory. commit 523fd47c29c24a865855d085a0036fc741203930 Merge: a1e50f6 2076f15 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 19:10:51 2009 +0200 Merge branch 'master' into doccleanup commit a1e50f6619ff1a302dd1fefbcb6b0cd62a653e7d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 19:06:16 2009 +0200 Group "getting started" documents into a walkthrough structure. commit e393b4f458263cb2f011cc5e5e67cdcc48610ea9 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 17:35:15 2009 +0200 Add screenshots for example-overview page. commit 8c84f307f73ab7b77a91e61ed18fdc685afebcc5 Merge: a16033a 34e272a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Mon Aug 3 11:03:41 2009 +0200 Merge branch 'master' into doccleanup commit a16033a287afe2f494401e24f02f046ec98d944c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 2 16:57:04 2009 +0200 Link to the real documentation, not just to the modules overview. commit 6c4ed0361c860e738b9344dfb191f55d35b3309f Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sun Aug 2 16:56:41 2009 +0200 A new layout for the examples. Needs a bit of shuffeling around, and more screenshots and descriptive text for some categories. commit 2dde2faa8f6e86acf738a808412c5e3c21c44658 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 22:39:27 2009 +0200 Cleanup the script-related groups a bit. commit a66227d0bed87c633a22a4d155f6a7f0061fc34e Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 22:17:16 2009 +0200 Add QContiguousCache to the list of containers as a special case. commit b22133eef28566f1c3c5d57aa0e8272af26da86a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 21:52:37 2009 +0200 Cleaning up groups of text- and string-related classes. Make a clear separation between classes that deal with string data (ie QString, QByteArray, QTextStream) and classes that are part of the "scribe" framework. Merge documentation from the Qt 4.0 introduction of Scribe into the richtext processing guide. commit b30ba739308905b6c06987cec47d4de1e5d172de Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 20:50:06 2009 +0200 One group of thread-related classes should be enough. commit a2511650577126026f98cb7416c159498f6f2db5 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 19:32:21 2009 +0200 Move documentation for classes into same directory as the respective header files (or implementation file, if one exists). This follows the Qt standard, and there is no particular reason why .qdoc files cannot live in src. Since there are a number of .cpp files that have only documentation it might also be an idea to rename the .qdoc files to .cpp and add them to the .pro-files to have them included in generated project files for easier access. commit f333ad71384cf42c20219a55d9dfa1e29a8c263e Merge: bad9ba5 5aed3db Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Sat Aug 1 12:04:55 2009 +0200 Merge branch 'master' into doccleanup commit bad9ba5468333be2f08da7f28950c980bc63c787 Merge: 49f38b7 c57ed13 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 19:31:04 2009 +0200 Merge branch 'master' into doccleanup commit 49f38b7afe3205eedccf655c0ad749d685cb3d52 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 19:29:46 2009 +0200 Starting to tie together the widgets and layouts groups and documentation. commit e6c4b8316b7c90b19815c0008a282983012c68b3 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 18:43:34 2009 +0200 This is all duplicate information that is better covered in the sql-programming guide. commit 620620ae969bed86d970519bead45762bd39ede1 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 18:37:53 2009 +0200 Consolidate style documentation. commit 01c78ff78888d3ccb50189206b9bcacaf13f5c80 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 17:13:44 2009 +0200 Split plugin-documentation into two: writing plugins and deploying plugins. commit a21f510c982dce06ac1769e61e93574f90cc48c4 Merge: da93c4c c6cdfcb Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 16:04:51 2009 +0200 Merge branch 'master' into doccleanup commit da93c4ccc25dd189dfb9b71bda28bd1e3a7230c1 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 14:19:47 2009 +0200 Some final module cleaning up. commit 9eb0815bbd01b7e30877110b53aa6f82b8e9221d Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:51:54 2009 +0200 Move remaining overview groups into one file. commit 65d4c4145386a409aeb1372ae5adc6f3e71e444b Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:51:34 2009 +0200 The "io" group should be about file access (be it local or networked). commit 1a3de3a7add6d9e7653e46b57b00852845384a42 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:36:51 2009 +0200 Kill the "time" group. The "How to use timers in your application" documentation covers the usecase. commit dbadf1c060e051dbac7f5c72528ef6a3125d5ba3 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:28:21 2009 +0200 Kill the group "misc". commit 7b7484b37b074d52af5c4ff9b138087a75965508 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:09:24 2009 +0200 Kill the "Environment" group. It was a random collection of classes, mostly ending up in there because of copy/paste (I suspect). commit b5271d81e7da6666d339041d028a0ae6c8ed75c4 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 13:08:37 2009 +0200 More moving of files and content. commit 96a707d25342c273cdd7629fc1e24b0ead4118de Merge: 4ffe572 18fbfdf Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 11:08:11 2009 +0200 Merge branch 'master' into doccleanup commit 4ffe572a954e99d604c1360fc55db25e8586436c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 02:03:07 2009 +0200 Workaround qdoc being difficult. commit 7f0e965c7cf613782e8189069444a4b549f0c11a Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 01:49:52 2009 +0200 Some more moving of files into meaningful directories. commit b0d67674469e57b29e60110888352ae955adcdd8 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 01:41:14 2009 +0200 Separate module documentation from frameworks documentation. Module documentation will list the classes in each module, how to use the respective libraries and headerfiles from a build-system perspective and what the legal implications are when linking against those libraries. The documentation of frameworks lives now in the frameworks subdirectory, or in dedicated subdirectories for the key frameworks. commit 45240a9c0eba9e42e6e441a55a407173a81a7344 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Fri Jul 31 00:47:54 2009 +0200 Group files in subdirectories that would correspond to top level topics. commit 896507f2f4fdc541fc436cf901a2beb72d35f6aa Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 21:48:45 2009 +0200 Group files in subdirectories that would correspond to top level topics. commit 37eb554f75d8b1d9d76993f6fcf632933c9616a2 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 20:57:39 2009 +0200 Fix a few links. commit 74027c3568c1bdbb9960d203266f4ccc5e89c05c Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 20:20:55 2009 +0200 Consolidate the two example documents into one page. commit cfc0fd3df050cf6c0e3229d22adfbff35aed46af Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 19:25:16 2009 +0200 The QtAssistant module is obsolete, remove it. QAssistantClient is in the list of obsolete classes. commit 0f86c7a176fc920669ca8a880afa141434f37767 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 18:56:14 2009 +0200 Get rid of \mainclass If we want to select a list of main classes, then we can use \ingroup for that, and document them coherently as part of the Fundamentals or a relevant framework. commit c4dfbc6bf58ef741fdab01538e75e9472e8370bf Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 18:23:55 2009 +0200 The new index page and respective style changes. commit a3e4eb6712e24a4d6156c340ee98671887a2b2fa Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 17:05:46 2009 +0200 Deployment group is gone. commit f03ee6192450db977bc2e4b07ffc613314b63a80 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 16:48:53 2009 +0200 All "lists of classes etc" are now in classes.qdoc... I hope. commit c5fb9a4b5208498454812d27578ac62ae23652a4 Author: Volker Hilsheimer <volker.hilsheimer@nokia.com> Date: Thu Jul 30 16:47:20 2009 +0200 Cleaning up files documenting deployment. Text need to be reviewed and merged.
Diffstat (limited to 'doc/src/development/qmake-manual.qdoc')
-rw-r--r--doc/src/development/qmake-manual.qdoc4320
1 files changed, 4320 insertions, 0 deletions
diff --git a/doc/src/development/qmake-manual.qdoc b/doc/src/development/qmake-manual.qdoc
new file mode 100644
index 0000000..181ba6a
--- /dev/null
+++ b/doc/src/development/qmake-manual.qdoc
@@ -0,0 +1,4320 @@
+/****************************************************************************
+**
+** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the either Technology Preview License Agreement or the
+** Beta Release License Agreement.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain
+** additional rights. These rights are described in the Nokia Qt LGPL
+** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this
+** package.
+**
+** GNU General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU
+** General Public License version 3.0 as published by the Free Software
+** Foundation and appearing in the file LICENSE.GPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU General Public License version 3.0 requirements will be
+** met: http://www.gnu.org/copyleft/gpl.html.
+**
+** If you are unsure which license is appropriate for your use, please
+** contact the sales department at http://qt.nokia.com/contact.
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+ \page qmake-manual.html
+ \title qmake Manual
+ \startpage {index.html}{Qt Reference Documentation}
+ \nextpage qmake Tutorial
+
+ \ingroup qttools
+ \keyword qmake
+
+ \c qmake is a tool that helps simplify the build
+ process for development project across different platforms. \c qmake
+ automates the generation of Makefiles so that only a few lines of
+ information are needed to create each Makefile. \c qmake can be used for
+ any software project, whether it is written in Qt or not.
+
+ \c qmake generates a Makefile based on the information in a project
+ file. Project files are created by the developer, and are usually
+ simple, but more sophisticated project files can be created for
+ complex projects.
+ \c qmake contains additional features to support development with Qt,
+ automatically including build rules for \l{moc.html}{moc}
+ and \l{uic.html}{uic}.
+ \c qmake can also generate projects for Microsoft Visual studio
+ without requiring the developer to change the project file.
+
+ \section1 Getting Started
+
+ The \l{qmake Tutorial} and guide to \l{qmake Common Projects} provide overviews
+ that aim to help new users get started with \c qmake.
+
+ \list
+ \o \l{qmake Tutorial}
+ \tableofcontents{1 qmake Tutorial}
+ \endlist
+
+ \list
+ \o \l{qmake Common Projects}
+ \tableofcontents{1 qmake Common Projects}
+ \endlist
+
+ \section1 Table of Contents
+
+ \list
+ \o \l{Using qmake}
+ \tableofcontents{1 Using qmake}
+ \o \l{qmake Project Files}
+ \tableofcontents{1 qmake Project Files}
+ \o \l{Running qmake}
+ \tableofcontents{1 Running qmake}
+ \o \l{qmake Platform Notes}
+ \tableofcontents{1 qmake Platform Notes}
+ \o \l{qmake Advanced Usage}
+ \tableofcontents{1 qmake Advanced Usage}
+ \o \l{Using Precompiled Headers}
+ \tableofcontents{1 Using Precompiled Headers}
+ \o \l{qmake Reference}
+ \tableofcontents{1 qmake Reference}
+ \o \l{qmake Variable Reference}
+ \tableofcontents{1 qmake Variable Reference}
+ \o \l{qmake Function Reference}
+ \tableofcontents{1 qmake Function Reference}
+ \o \l{Configuring qmake's Environment}
+ \tableofcontents{1 Configuring qmake's Environment}
+ \endlist
+*/
+
+/*!
+ \page qmake-using.html
+ \title Using qmake
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Manual
+ \nextpage qmake Project Files
+
+ \c qmake provides a project-oriented system for managing the build
+ process for applications, libraries, and other components. This
+ approach gives developers control over the source files used, and
+ allows each of the steps in the process to be described concisely,
+ typically within a single file. \c qmake expands the information in
+ each project file to a Makefile that executes the necessary commands
+ for compiling and linking.
+
+ In this document, we provide a basic introduction to project files,
+ describe some of the main features of \c qmake, and show how to use
+ \c qmake on the command line.
+
+ \section1 Describing a Project
+
+ Projects are described by the contents of project (\c .pro) files.
+ The information within these is used by \c qmake to generate a Makefile
+ containing all the commands that are needed to build each project.
+ Project files typically contain a list of source and header files,
+ general configuration information, and any application-specific details,
+ such as a list of extra libraries to link against, or a list of extra
+ include paths to use.
+
+ Project files can contain a number of different elements, including
+ comments, variable declarations, built-in functions, and some simple
+ control structures. In most simple projects, it is only necessary
+ to declare the source and header files that are used to build the
+ project with some basic configuration options.
+
+ Complete examples of project files can be found in the
+ \l{qmake Tutorial}.
+ An introduction to project files can be found in the
+ \l{qmake Project Files} chapter, and a more detailed description is
+ available in the \l{qmake Reference}.
+
+ \section1 Building a Project
+
+ For simple projects, you only need to run \c qmake in the top
+ level directory of your project. By default, \c qmake generates a
+ Makefile that you then use to build the project, and you can then
+ run your platform's \c make tool to build the project.
+
+ \c qmake can also be used to generate project files. A full
+ description of \c{qmake}'s command line options can be found in the
+ \l{Running qmake} chapter of this manual.
+
+ \section1 Using Precompiled Headers
+
+ In large projects, it is possible to take advantage of precompiled
+ header files to speed up the build process. This feature is described
+ in detail in the \l{Using Precompiled Headers} chapter.
+*/
+
+/*!
+ \page qmake-project-files.html
+ \title qmake Project Files
+ \contentspage {qmake Manual}{Contents}
+ \previouspage Using qmake
+ \nextpage Running qmake
+
+ Project files contain all the information required by \c qmake to build
+ your application, library, or plugin. The resources used by your project
+ are generally specified using a series of declarations, but support for
+ simple programming constructs allow you to describe different build
+ processes for different platforms and environments.
+
+ \tableofcontents
+
+ \section1 Project File Elements
+
+ The project file format used by \c qmake can be used to support both
+ simple and fairly complex build systems. Simple project files will
+ use a straightforward declarative style, defining standard variables
+ to indicate the source and header files that are used in the project.
+ Complex projects may use the control flow structures to fine-tune the
+ build process.
+
+ The following sections describe the different types of elements used
+ in project files.
+
+ \section2 Variables
+
+ In a project file, variables are used to hold lists of strings.
+ In the simplest projects, these variables inform \c qmake about the
+ configuration options to use, or supply filenames and paths to use
+ in the build process.
+
+ \c qmake looks for certain variables in each project file, and it
+ uses the contents of these to determine what it should write to a
+ Makefile. For example, the list of values in the \c HEADERS and
+ \c SOURCES variables are used to tell \c qmake about header and
+ source files in the same directory as the project file.
+
+ Variables can also be used internally to store temporary lists of values,
+ and existing lists of values can be overwritten or extended with new
+ values.
+
+ The following lines show how lists of values are assigned to variables:
+
+ \snippet doc/src/snippets/qmake/variables.pro 0
+
+ Note that the first assignment only includes values that are specified on
+ the same line as the \c SOURCES variable. The second assignment splits
+ the items across lines by using the \c \\ character.
+
+ The list of values in a variable is extended in the following way:
+
+ \snippet doc/src/snippets/qmake/variables.pro 1
+
+ The \c CONFIG variable is another special variable that \c qmake
+ uses when generating a Makefile. It is discussed in the section on
+ \l{#GeneralConfiguration}{general configuration} later in this chapter.
+ In the above line, \c qt is added to the list of existing values
+ contained in \c CONFIG.
+
+ The following table lists the variables that \c qmake recognizes, and
+ describes what they should contain.
+
+ \table
+ \header \o Variable \o Contents
+ \row \o CONFIG \o General project configuration options.
+ \row \o DESTDIR \o The directory in which the executable or binary file will
+ be placed.
+ \row \o FORMS \o A list of UI files to be processed by \c uic.
+ \row \o HEADERS \o A list of filenames of header (.h) files used when
+ building the project.
+ \row \o QT \o Qt-specific configuration options.
+ \row \o RESOURCES \o A list of resource (.rc) files to be included in the
+ final project. See the \l{The Qt Resource System} for
+ more information about these files.
+ \row \o SOURCES \o A list of source code files to be used when building
+ the project.
+ \row \o TEMPLATE \o The template to use for the project. This determines
+ whether the output of the build process will be an
+ application, a library, or a plugin.
+ \endtable
+
+ The contents of a variable can be read by prepending the variable name with
+ \c $$. This can be used to assign the contents of one variable to another:
+
+ \snippet doc/src/snippets/qmake/dereferencing.pro 0
+
+ The \c $$ operator is used extensively with built-in functions that operate
+ on strings and lists of values. These are described in the chapter on
+ \l{qmake Advanced Usage}.
+
+ \section3 Whitespace
+
+ Normally, variables are used to contain whitespace-separated lists
+ of values. However, it is sometimes necessary to specify values containing
+ spaces. These must be quoted by using the
+ \l{qmake Function Reference#quote-string}{quote()} function in the following way:
+
+ \snippet doc/src/snippets/qmake/quoting.pro 0
+
+ The quoted text is treated as a single item in the list of values held by
+ the variable. A similar approach is used to deal with paths that contain
+ spaces, particularly when defining the
+ \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH} and
+ \l{qmake Variable Reference#LIBS}{LIBS} variables for the Windows platform.
+ In cases like these, the \l{qmake Function Reference#quote(string)}{quote()}
+ function can be used in the following way:
+
+ \snippet doc/src/snippets/qmake/spaces.pro quoting include paths with spaces
+
+ \section2 Comments
+
+ You can add comments to project files. Comments begin with the \c
+ # character and continue to the end of the same line. For example:
+
+ \snippet doc/src/snippets/qmake/comments.pro 0
+
+ To include the \c # character in variable assignments, it is necessary
+ to use the contents of the built-in \c LITERAL_HASH variable. See the
+ \l{qmake Variable Reference#LITERAL_HASH}{variable reference} for more
+ information.
+
+ \section2 Built-in Functions and Control Flow
+
+ \c qmake provides a number of built-in functions to allow the contents
+ of variables to be processed. The most commonly used function in simple
+ project files is the \c include function which takes a filename as an
+ argument. The contents of the given file are included in the project
+ file at the place where the \c include function is used.
+ The \c include function is most commonly used to include other project
+ files:
+
+ \snippet doc/src/snippets/qmake/include.pro 0
+
+ Support for conditional structures is made available via
+ \l{qmake Advanced Usage#scopes}{scopes} that behave like \c if
+ statements in programming languages:
+
+ \snippet doc/src/snippets/qmake/scopes.pro 0
+
+ The assignments inside the braces are only made if the condition is
+ true. In this case, the special \c win32 variable must be set; this
+ happens automatically on Windows, but this can also be specified on
+ other platforms by running \c qmake with the \c{-win32} command line
+ option (see \l{Running qmake} for more information). The opening
+ brace must stand on the same line as the condition.
+
+ Simple loops are constructed by iterating over lists of values using
+ the built-in \c for function. The following code adds directories
+ to the \l{qmake Variable Reference#SUBDIRS}{SUBDIRS} variable, but
+ only if they exist:
+
+ \snippet doc/src/snippets/qmake/functions.pro 0
+
+ More complex operations on variables that would usually require loops
+ are provided by built-in functions such as \c find, \c unique, and
+ \c count. These functions, and many others are provided to manipulate
+ strings and paths, support user input, and call external tools. A list
+ of the functions available can be found in the
+ \l{qmake Advanced Usage} chapter of this manual.
+
+ \section1 Project Templates
+
+ The \c TEMPLATE variable is used to define the type of project that will
+ be built. If this is not declared in the project file, \c qmake assumes
+ that an application should be built, and will generate an appropriate
+ Makefile (or equivalent file) for the purpose.
+
+ The types of project available are listed in the following table with
+ information about the files that \c qmake will generate for each of them:
+
+ \table
+ \header \o Template \o Description of \c qmake output
+ \row \o app (default) \o Creates a Makefile to build an application.
+ \row \o lib \o Creates a Makefile to build a library.
+ \row \o subdirs \o Creates a Makefile containing rules for the
+ subdirectories specified using the \l{qmake Variable Reference#SUBDIRS}{SUBDIRS}
+ variable. Each subdirectory must contain its own project file.
+ \row \o vcapp \o Creates a Visual Studio Project file to build
+ an application.
+ \row \o vclib \o Creates a Visual Studio Project file to build a library.
+ \endtable
+
+ See the \l{qmake Tutorial} for advice on writing project files for
+ projects that use the \c app and \c lib templates.
+
+ When the \c subdirs template is used, \c qmake generates a Makefile
+ to examine each specified subdirectory, process any project file it finds
+ there, and run the platform's \c make tool on the newly-created Makefile.
+ The \l{qmake Variable Reference#SUBDIRS}{SUBDIRS} variable is used to
+ contain a list of all the subdirectories to be processed.
+
+ \target GeneralConfiguration
+ \section1 General Configuration
+
+ The \l{qmake Variable Reference#CONFIG}{CONFIG variable} specifies the
+ options and features that the compiler should use and the libraries that
+ should be linked against. Anything can be added to the \c CONFIG variable,
+ but the options covered below are recognized by \c qmake internally.
+
+ The following options control the compiler flags that are used to build the
+ project:
+
+ \table
+ \header \o Option \o Description
+ \row \o release \o The project is to be built in release mode.
+ This is ignored if \c debug is also specified.
+ \row \o debug \o The project is to be built in debug mode.
+ \row \o debug_and_release \o The project is built in \e both debug and
+ release modes.
+ \row \o debug_and_release_target \o The project is built in \e both debug
+ and release modes. TARGET is built into \e both the debug and release directories.
+ \row \o build_all \o If \c debug_and_release is specified, the project is
+ built in both debug and release modes by default.
+ \row \o autogen_precompile_source \o Automatically generates a \c .cpp file that includes
+ the precompiled header file specified in the .pro file.
+ \row \o ordered \o When using the \c subdirs template, this option
+ specifies that the directories listed should be processed in the
+ order in which they are given.
+ \row \o warn_on \o The compiler should output as many warnings as possible.
+ This is ignored if \c warn_off is specified.
+ \row \o warn_off \o The compiler should output as few warnings as possible.
+ \row \o copy_dir_files \o Enables the install rule to also copy directories, not just files.
+ \endtable
+
+ The \c debug_and_release option is special in that it enables \e both debug and
+ release versions of a project to be built. In such a case, the Makefile that
+ \c qmake generates includes a rule that builds both versions, and this can be
+ invoked in the following way:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 0
+
+ Adding the \c build_all option to the \c CONFIG variable makes this rule
+ the default when building the project, and installation targets will be
+ created for both debug and release builds.
+
+ Note that each of the options specified in the \c CONFIG variable can also be
+ used as a scope condition.
+ You can test for the presence of certain configuration options by using the
+ built-in \l{qmake Function Reference#CONFIG(config)}{CONFIG()} function.
+ For example, the following lines show the function as the condition in a scope
+ to test whether only the \c opengl option is in use:
+
+ \snippet doc/src/snippets/qmake/configscopes.pro 4
+ \snippet doc/src/snippets/qmake/configscopes.pro 5
+
+ This enables different configurations to be defined for \c release and
+ \c debug builds, and is described in more detail in the
+ \l{qmake Advanced Usage#Scopes}{Scopes} section of the
+ \l{qmake Advanced Usage}{Advanced Usage} chapter of this manual.
+
+ The following options define the type of project to be built. Note that some
+ of these options only take effect when used on the relevant platform. On other
+ platforms, they have no effect.
+
+ \table
+ \header \o Option \o Description
+ \row \o qt \o The project is a Qt application and should link against the Qt
+ library. You can use the \c QT variable to control any additional
+ Qt modules that are required by your application.
+ \row \o thread \o The project is a multi-threaded application.
+ \row \o x11 \o The project is an X11 application or library.
+ \endtable
+
+ When using \l{qmake Variable Reference#TEMPLATE}{application or library project
+ templates}, more specialized configuration options can be used to fine tune the
+ build process. These are explained in details in the
+ \l{qmake-common-projects.html}{Common Projects} chapter of this manual.
+
+ For example, if your application uses the Qt library and you want to
+ build it as a multi-threaded application in \c debug mode, your project
+ file will contain the following line:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 1
+
+ Note, that you must use "+=", not "=", or \c qmake will not be able to
+ use Qt's configuration to determine the settings needed for your project.
+
+ \section1 Declaring Qt Libraries
+
+ If the \c CONFIG variable contains the \c qt value, qmake's support for Qt
+ applications is enabled. This makes it possible to fine-tune which of the
+ Qt modules are used by your application. This is achieved with the \c QT
+ variable which can be used to declare the required extension modules.
+ For example, we can enable the XML and network modules in the following way:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 2
+
+ Note that \c QT includes the \c core and \c gui modules by default, so the
+ above declaration \e adds the network and XML modules to this default list.
+ The following assignment \e omits the default modules, and will lead to
+ errors when the application's source code is being compiled:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 3
+
+ If you want to build a project \e without the \c gui module, you need to
+ exclude it with the "-=" operator. By default, \c QT contains both
+ \c core and \c gui, so the following line will result in a minimal
+ Qt project being built:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 4
+
+ The table below shows the options that can be used with the \c QT variable
+ and the features that are associated with each of them:
+
+ \table
+ \header \o Option \o Features
+ \row \o core (included by default) \o QtCore module
+ \row \o gui (included by default) \o QtGui module
+ \row \o network \o QtNetwork module
+ \row \o opengl \o QtOpenGL module
+ \row \o sql \o QtSql module
+ \row \o svg \o QtSvg module
+ \row \o xml \o QtXml module
+ \row \o xmlpatterns \o QtXmlPatterns module
+ \row \o qt3support \o Qt3Support module
+ \endtable
+
+ Note that adding the \c opengl option to the \c QT variable automatically
+ causes the equivalent option to be added to the \c CONFIG variable.
+ Therefore, for Qt applications, it is not necessary to add the \c opengl
+ option to both \c CONFIG and \c{QT}.
+
+ \section1 Configuration Features
+
+ \c qmake can be set up with extra configuration features that are specified
+ in feature (.prf) files. These extra features often provide support for
+ custom tools that are used during the build process. To add a feature to
+ the build process, append the feature name (the stem of the feature filename)
+ to the \c CONFIG variable.
+
+ For example, \c qmake can configure the build process to take advantage
+ of external libraries that are supported by
+ \l{http://www.freedesktop.org/wiki/Software_2fpkgconfig}{pkg-config},
+ such as the D-Bus and ogg libraries, with the following lines:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 5
+
+ More information about features can be found in the
+ \l{qmake Advanced Usage#Adding New Configuration Features}
+ {Adding New Configuration Features} section of the \l{qmake Advanced Usage}
+ chapter.
+
+ \section1 Declaring Other Libraries
+
+ If you are using other libraries in your project in addition to those
+ supplied with Qt, you need to specify them in your project file.
+
+ The paths that \c qmake searches for libraries and the specific libraries
+ to link against can be added to the list of values in the
+ \l{qmake Variable Reference#LIBS}{LIBS} variable. The paths to the libraries
+ themselves can be given, or the familiar Unix-style notation for specifying
+ libraries and paths can be used if preferred.
+
+ For example, the following lines show how a library can be specified:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 6
+
+ The paths containing header files can also be specified in a similar way
+ using the \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH} variable.
+
+ For example, it is possible to add several paths to be searched for header
+ files:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 7
+*/
+
+/*!
+ \page qmake-running.html
+ \title Running qmake
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Project Files
+ \nextpage qmake Platform Notes
+
+ The behavior of \c qmake can be customized when it is run by
+ specifying various options on the command line. These allow the
+ build process to be fine-tuned, provide useful diagnostic
+ information, and can be used to specify the target platform for
+ your project.
+
+ \tableofcontents
+
+ \target Commands
+ \section1 Command-Line Options
+
+ \section2 Syntax
+
+ The syntax used to run \c qmake takes the following simple form:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 8
+
+ \c qmake supports two different modes of operation: In the default mode,
+ \c qmake will use the description in a project file to generate a Makefile,
+ but it is also possible to use \c qmake to generate project files.
+ If you want to explicitly set the mode, you must specify it before all
+ other options. The \c mode can be either of the following two values:
+
+ \list
+ \o \c -makefile \BR
+ \c qmake output will be a Makefile.
+ \o \c -project \BR
+ \c qmake output will be a project file. \BR
+\bold{Note:} It is likely that the created file will need to be edited for example adding the \c QT variable to suit what modules are required for the project.
+ \endlist
+
+ The following \c options are used to specify both general and mode-specific
+ settings. Options that only apply to the Makefile mode are described in the
+ \l{#MakefileMode}{Makefile Mode Options} section; options that influence the
+ creation of project files are described in the
+ \l{#ProjectMode}{Project File Options} section.
+
+ The \c files argument represents a list of one or more project files, separated
+ by spaces.
+
+ \section2 Options
+
+ A wide range of options can be specified on the command line to \c qmake in
+ order to customize the build process, and to override default settings for
+ your platform. The following basic options provide usage information, specify
+ where \c qmake writes the output file, and control the level of debugging
+ information that will be written to the console:
+
+ \list
+ \o \c -help \BR
+ \c qmake will go over these features and give some useful help.
+ \o \c -o file \BR
+ \c qmake output will be directed to \e file. If this option
+ is not specified, \c qmake will try to use a suitable file name for its
+ output, depending on the mode it is running in.\BR
+ If '-' is specified, output is directed to stdout.
+ \o \c -d \BR
+ \c qmake will output debugging information.
+ \endlist
+
+ For projects that need to be built differently on each target platform, with
+ many subdirectories, you can run \c qmake with each of the following
+ options to set the corresponding platform-specific variable in each
+ project file:
+
+ \list
+ \o \c -unix \BR
+ \c qmake will run in unix mode. In this mode, Unix file
+ naming and path conventions will be used, additionally testing for \c unix
+ (as a scope) will succeed. This is the default mode on all Unices.
+ \o \c -macx \BR
+ \c qmake will run in Mac OS X mode. In this mode, Unix file
+ naming and path conventions will be used, additionally testing for \c macx
+ (as a scope) will succeed. This is the default mode on Mac OS X.
+ \o \c -win32 \BR
+ \c qmake will run in win32 mode. In this mode, Windows file naming and path
+ conventions will be used, additionally testing for \c win32 (as a scope)
+ will succeed. This is the default mode on Windows.
+ \endlist
+
+ The template used for the project is usually specified by the \c TEMPLATE
+ variable in the project file. We can override or modify this by using the
+ following options:
+
+ \list
+ \o \c -t tmpl \BR
+ \c qmake will override any set \c TEMPLATE variables with tmpl, but only
+ \e after the .pro file has been processed.
+ \o \c -tp prefix \BR
+ \c qmake will add the prefix to the \c TEMPLATE variable.
+ \endlist
+
+ The level of warning information can be fine-tuned to help you find problems in
+ your project file:
+
+ \list
+ \o \c -Wall \BR
+ \c qmake will report all known warnings.
+ \o \c -Wnone \BR
+ No warning information will be generated by \c qmake.
+ \o \c -Wparser \BR
+ \c qmake will only generate parser warnings. This will alert
+ you to common pitfalls and potential problems in the parsing of your
+ project files.
+ \o \c -Wlogic \BR
+ \c qmake will warn of common pitfalls and potential problems in your
+ project file. For example, \c qmake will report whether a file is placed
+ into a list of files multiple times, or if a file cannot be found.
+ \endlist
+
+ \target MakefileMode
+ \section2 Makefile Mode Options
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 9
+
+ In Makefile mode, \c qmake will generate a Makefile that is used to build the
+ project. Additionally, the following options may be used in this mode to
+ influence the way the project file is generated:
+
+ \list
+ \o \c -after \BR
+ \c qmake will process assignments given on the command line after
+ the specified files.
+ \o \c -nocache \BR
+ \c qmake will ignore the .qmake.cache file.
+ \o \c -nodepend \BR
+ \c qmake will not generate any dependency information.
+ \o \c -cache file \BR
+ \c qmake will use \e file as the cache file, ignoring any other
+ .qmake.cache files found.
+ \o \c -spec spec \BR
+ \c qmake will use \e spec as a path to platform and compiler information,
+ and the value of \c QMAKESPEC will be ignored.
+ \endlist
+
+ You may also pass \c qmake assignments on the command line;
+ they will be processed before all of the files specified. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 10
+
+ This will generate a Makefile, from test.pro with Unix pathnames. However
+ many of the specified options aren't necessary as they are the default.
+ Therefore, the line can be simplified on Unix to:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 11
+
+ If you are certain you want your variables processed after the
+ files specified, then you may pass the \c -after option. When this
+ is specified, all assignments on the command line after the \c -after
+ option will be postponed until after the specified files are parsed.
+
+ \target ProjectMode
+ \section2 Project Mode Options
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 12
+
+ In project mode, \c qmake will generate a project file. Additionally, you
+ may supply the following options in this mode:
+
+ \list
+ \o \c -r \BR
+ \c qmake will look through supplied directories recursively
+ \o \c -nopwd \BR
+ \c qmake will not look in your current working directory for
+ source code and only use the specified \c files
+ \endlist
+
+ In this mode, the \c files argument can be a list of files or directories.
+ If a directory is specified, it will be included in the \c DEPENDPATH
+ variable, and relevant code from there will be included in the generated
+ project file. If a file is given, it will be appended to the correct
+ variable, depending on its extension; for example, UI files are added
+ to \c FORMS, and C++ files are added to \c SOURCES.
+
+ You may also pass assignments on the command line in this mode. When doing
+ so, these assignments will be placed last in the generated project file.
+*/
+
+/*!
+ \page qmake-platform-notes.html
+ \title qmake Platform Notes
+ \contentspage {qmake Manual}{Contents}
+ \previouspage Running qmake
+ \nextpage qmake Advanced Usage
+
+ Many cross-platform projects can be handled by the \c{qmake}'s basic
+ configuration features. On some platforms, it is sometimes useful, or even
+ necessary, to take advantage of platform-specific features. \c qmake knows
+ about many of these features, and these can be accessed via specific
+ variables that only have an effect on the platforms where they are relevant.
+
+ \tableofcontents
+
+ \section1 Mac OS X
+
+ Features specific to this platform include support for creating universal
+ binaries, frameworks and bundles.
+
+ \section2 Source and Binary Packages
+
+ The version of \c qmake supplied in source packages is configured slightly
+ differently to that supplied in binary packages in that it uses a different
+ feature specification. Where the source package typically uses the
+ \c macx-g++ specification, the binary package is typically configured to
+ use the \c macx-xcode specification.
+
+ Users of each package can override this configuration by invoking \c qmake
+ with the \c -spec option (see \l{Running qmake} for more information). This
+ makes it possible, for example, to use \c qmake from a binary package to
+ create a Makefile in a project directory with the following command line
+ invocation:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 13
+
+ \section2 Using Frameworks
+
+ \c qmake is able to automatically generate build rules for linking against
+ frameworks in the standard framework directory on Mac OS X, located at
+ \c{/Library/Frameworks/}.
+
+ Directories other than the standard framework directory need to be specified
+ to the build system, and this is achieved by appending linker options to the
+ \l{qmake Variable Reference#QMAKE_LFLAGS}{QMAKE_LFLAGS} variable, as shown
+ in the following example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 14
+
+ The framework itself is linked in by appending the \c{-framework} options and
+ the name of the framework to the \l{qmake Variable Reference#LIBS}{LIBS}
+ variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 15
+
+ \section2 Creating Frameworks
+
+ Any given library project can be configured so that the resulting library
+ file is placed in a
+ \l{http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WhatAreFrameworks.html}
+ {framework}, ready for deployment. To do this, set up the project to use the
+ \l{qmake Variable Reference#TEMPLATE}{\c lib template} and add the
+ \c lib_bundle option to the
+ \l{qmake Variable Reference#CONFIG}{CONFIG} variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 16
+
+ The data associated with the library is specified using the
+ \l{qmake Variable Reference#QMAKE_BUNDLE_DATA}{QMAKE_BUNDLE_DATA}
+ variable. This holds items that will be installed with a library
+ bundle, and is often used to specify a collection of header files,
+ as in the following example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 17
+
+ Here, the \c FRAMEWORK_HEADERS variable is a user-defined variable that
+ is used to define the headers required to use a particular framework.
+ Appending it to the \c QMAKE_BUNDLE_DATA variable ensures that the
+ information about these headers are added to the collection of
+ resources that will be installed with the library bundle. Also, the
+ framework's name and version are specified by
+ \l{qmake Variable Reference#QMAKE_FRAMEWORK_BUNDLE_NAME}
+ {QMAKE_FRAMEWORK_BUNDLE_NAME}
+ and \l{qmake Variable Reference#QMAKE_FRAMEWORK_VERSION}
+ {QMAKE_FRAMEWORK_VERSION} variables. By default, the values used for
+ these are obtained from the \l{qmake Variable Reference#TARGET}{TARGET}
+ and \l{qmake Variable Reference#VERSION}{VERSION} variables.
+
+ See \l{Deploying an Application on Mac OS X} for more information about
+ deploying applications and libraries.
+
+ \section2 Creating Universal Binaries
+
+ To create a universal binary for your application, you need to be using
+ a version of Qt that has been configured with the \c{-universal} option.
+
+ The architectures to be supported in the binary are specified with the
+ \l{qmake Variable Reference#CONFIG}{CONFIG} variable. For example, the
+ following assignment causes \c qmake to generate build rules to create
+ a universal binary for both PowerPC and x86 architectures:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 18
+
+ Additionally, developers using a PowerPC-based platform need to set the
+ \l{qmake Variable Reference#QMAKE_MAC_SDK}{QMAKE_MAC_SDK} variable.
+ This process is discussed in more detail in the
+ \l{Deploying an Application on Mac OS X#Architecture Dependencies}{deployment guide for Mac OS X}.
+
+ \section2 Creating and Moving Xcode Projects
+
+ Developers on Mac OS X can take advantage of \c{qmake}'s support for Xcode
+ project files, as described in
+ \l{Qt is Mac OS X Native#Development Tools}{Qt is Mac OS X Native},
+ by running \c qmake to generate an Xcode project from an existing \c qmake
+ project files. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 19
+
+ Note that, if a project is later moved on the disk, \c qmake must be run
+ again to process the project file and create a new Xcode project file.
+
+ \section2 On supporting two build targets simultaneously
+
+ Implementing this is currently not feasible, because the XCode
+ concept of Active Build Configurations is conceptually different
+ from the qmake idea of build targets.
+
+ The XCode Active Build Configurations settings are for modifying
+ xcode configurations, compiler flags and similar build
+ options. Unlike Visual Studio, XCode does not allow for the
+ selection of specific library files based on whether debug or
+ release build configurations are selected. The qmake debug and
+ release settings control which library files are linked to the
+ executable.
+
+ It is currently not possible to set files in XCode configuration
+ settings from the qmake generated xcode project file. The way the
+ libraries are linked in the "Frameworks & Libraries" phase in the
+ XCode build system.
+
+ Furthermore, The selected "Active Build Configuration" is stored
+ in a .pbxuser file, which is generated by xcode on first load, not
+ created by qmake.
+
+ \section1 Windows
+
+ Features specific to this platform include support for creating Visual
+ Studio project files and handling manifest files when deploying Qt
+ applications developed using Visual Studio 2005.
+
+ \section2 Creating Visual Studio Project Files
+
+ Developers using Visual Studio to write Qt applications can use the
+ Visual Studio integration facilities provided with the
+ \l{Qt Commercial Editions} and do not need to worry about how
+ project dependencies are managed.
+
+ However, some developers may need to import an existing \c qmake project
+ into Visual Studio. \c qmake is able to take a project file and create a
+ Visual Studio project that contains all the necessary information required
+ by the development environment. This is achieved by setting the \c qmake
+ \l{qmake Variable Reference#TEMPLATE}{project template} to either \c vcapp
+ (for application projects) or \c vclib (for library projects).
+
+ This can also be set using a command line option, for example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 20
+
+ It is possible to recursively generate \c{.vcproj} files in subdirectories
+ and a \c{.sln} file in the main directory, by typing:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 21
+
+ Each time you update the project file, you need to run \c qmake to generate
+ an updated Visual Studio project.
+
+ \note If you are using the Visual Studio Add-in, you can import \c .pro
+ files via the \gui{Qt->Import from .pro file} menu item.
+
+ \section2 Visual Studio 2005 Manifest Files
+
+ When deploying Qt applications built using Visual Studio 2005, it is
+ necessary to ensure that the manifest file, created when the application
+ was linked, is handled correctly. This is handled automatically for
+ projects that generate DLLs.
+
+ Removing manifest embedding for application executables can be done with
+ the following assignment to the \l{qmake Variable Reference#CONFIG}
+ {CONFIG} variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 22
+
+ Also, the manifest embedding for DLLs can be removed with the following
+ assignment to the \l{qmake Variable Reference#CONFIG}{CONFIG} variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 23
+
+ This is discussed in more detail in the
+ \l{Deploying an Application on Windows#Visual Studio 2005 Onwards}
+ {deployment guide for Windows}.
+*/
+
+/*!
+ \page qmake-reference.html
+ \title qmake Reference
+ \contentspage {qmake Manual}{Contents}
+ \previouspage Using Precompiled Headers
+ \nextpage qmake Variable Reference
+
+ This reference is a detailed index of all the variables and function
+ that are available for use in \c qmake project files.
+
+ \section1 Variable Reference
+
+ The \l{qmake Variable Reference} describes the variables that are
+ recognized by \c qmake when configuring the build process for
+ projects.
+
+ \section1 Function Reference
+
+ The \l{qmake Function Reference} describes the function that can be
+ used to process the contents of variables defined in project files.
+
+ \target FrequentlyUsedVariables
+ \section1 Frequently Used Variables
+
+ The following variables are frequently used in project files to describe
+ common aspects of the build process. These are fully described in the
+ \l{qmake-variable-reference.html}{Variable Reference}.
+
+ \list
+ \o \l{qmake Variable Reference#CONFIG}{CONFIG}
+ \o \l{qmake Variable Reference#DEF_FILE}{DEF_FILE}
+ \o \l{qmake Variable Reference#DEFINES}{DEFINES}
+ \o \l{qmake Variable Reference#DESTDIR}{DESTDIR}
+ \o \l{qmake Variable Reference#DISTFILES}{DISTFILES}
+ \o \l{qmake Variable Reference#DLLDESTDIR}{DLLDESTDIR}
+ \o \l{qmake Variable Reference#FORMS}{FORMS}
+ \o \l{qmake Variable Reference#FORMS3}{FORMS3}
+ \o \l{qmake Variable Reference#GUID}{GUID}
+ \o \l{qmake Variable Reference#HEADERS}{HEADERS}
+ \o \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH}
+ \o \l{qmake Variable Reference#LEXSOURCES}{LEXSOURCES}
+ \o \l{qmake Variable Reference#LIBS}{LIBS}
+ \o \l{qmake Variable Reference#MOC_DIR}{MOC_DIR}
+ \o \l{qmake Variable Reference#OBJECTS_DIR}{OBJECTS_DIR}
+ \o \l{qmake Variable Reference#QT}{QT}
+ \o \l{qmake Variable Reference#RCC_DIR}{RCC_DIR}
+ \o \l{qmake Variable Reference#REQUIRES}{REQUIRES}
+ \o \l{qmake Variable Reference#RESOURCES}{RESOURCES}
+ \o \l{qmake Variable Reference#SOURCES}{SOURCES}
+ \o \l{qmake Variable Reference#SUBDIRS}{SUBDIRS}
+ \o \l{qmake Variable Reference#TARGET}{TARGET}
+ \o \l{qmake Variable Reference#TEMPLATE}{TEMPLATE}
+ \o \l{qmake Variable Reference#TRANSLATIONS}{TRANSLATIONS}
+ \o \l{qmake Variable Reference#UI_DIR}{UI_DIR}
+ \o \l{qmake Variable Reference#UI_HEADERS_DIR}{UI_HEADERS_DIR}
+ \o \l{qmake Variable Reference#UI_SOURCES_DIR}{UI_SOURCES_DIR}
+ \o \l{qmake Variable Reference#VERSION}{VERSION}
+ \o \l{qmake Variable Reference#YACCSOURCES}{YACCSOURCES}
+ \endlist
+
+ \section1 Environment Variables and Configuration
+
+ The \l{Configuring qmake's Environment} chapter of this manual
+ describes the environment variables that \c qmake uses when
+ configuring the build process.
+*/
+
+/*!
+ \page qmake-variable-reference.html
+ \title qmake Variable Reference
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Reference
+ \nextpage qmake Function Reference
+
+ \c{qmake}'s fundamental behavior is influenced by variable declarations that
+ define the build process of each project. Some of these declare resources,
+ such as headers and source files, that are common to each platform; others
+ are used to customize the behavior of compilers and linkers on specific
+ platforms.
+
+ Platform-specific variables follow the naming pattern of the
+ variables which they extend or modify, but include the name of the relevant
+ platform in their name. For example, \c QMAKE_LIBS can be used to specify a list
+ of libraries that a project needs to link against, and \c QMAKE_LIBS_X11 can be
+ used to extend or override this list.
+
+ \tableofcontents{3}
+
+ \target CONFIG
+ \section1 CONFIG
+
+ The \c CONFIG variable specifies project configuration and
+ compiler options. The values will be recognized internally by
+ \c qmake and have special meaning. They are as follows.
+
+ These \c CONFIG values control compilation flags:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o release \o The project is to be built in release mode.
+ This is ignored if \c debug is also specified.
+ \row \o debug \o The project is to be built in debug mode.
+ \row \o debug_and_release \o The project is built in \e both debug and
+ release modes. This can have some unexpected side effects (see
+ below for more information).
+ \row \o build_all \o If \c debug_and_release is specified, the project is
+ built in both debug and release modes by default.
+ \row \o ordered \o When using the \c subdirs template, this option
+ specifies that the directories listed should be processed in the
+ order in which they are given.
+ \row \o precompile_header \o Enables support for the use of
+ \l{Using Precompiled Headers}{precompiled headers} in projects.
+ \row \o warn_on \o The compiler should output as many warnings as possible.
+ This is ignored if \c warn_off is specified.
+ \row \o warn_off \o The compiler should output as few warnings as possible.
+ \omit
+ \row \o qt_debug \o Specifies that the project should be built against
+ debug versions of the Qt libraries specified using the
+ \l{#QT}{QT} variable.
+ \row \o qt_release \o Specifies that the project should be built against
+ release versions of the Qt libraries specified using the
+ \l{#QT}{QT} variable.
+ \endomit
+ \endtable
+
+ Since the \c debug option overrides the \c release option when both are
+ defined in the \c CONFIG variable, it is necessary to use the
+ \c debug_and_release option if you want to allow both debug and release
+ versions of a project to be built. In such a case, the Makefile that
+ \c qmake generates includes a rule that builds both versions, and this can
+ be invoked in the following way:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 24
+
+ When linking a library, \c qmake relies on the underlying platform to know
+ what other libraries this library links against. However, if linking
+ statically, \c qmake will not get this information unless we use the following
+ \c CONFIG options:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o create_prl \o This option enables \c qmake to track these
+ dependencies. When this option is enabled, \c qmake will create a file
+ ending in \c .prl which will save meta-information about the library
+ (see \l{LibDepend}{Library Dependencies} for more info).
+ \row \o link_prl \o When this is enabled, \c qmake will process all
+ libraries linked to by the application and find their meta-information
+ (see \l{LibDepend}{Library Dependencies} for more info).
+ \endtable
+
+ Please note that \c create_prl is required when \e {building} a
+ static library, while \c link_prl is required when \e {using} a
+ static library.
+
+ On Windows (or if Qt is configured with \c{-debug_and_release}, adding the
+ \c build_all option to the \c CONFIG variable makes this rule the default
+ when building the project, and installation targets will be created for
+ both debug and release builds.
+
+ Additionally, adding \c debug_and_release to the \c CONFIG variable will
+ cause both \c debug and \c release to be defined in the contents of
+ \c CONFIG. When the project file is processed, the
+ \l{qmake Advanced Usage#Scopes}{scopes} that test for each value will be
+ processed for \e both debug and release modes. The \c{build_pass} variable
+ will be set for each of these mode, and you can test for this to perform
+ build-specific tasks. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 25
+
+ As a result, it may be useful to define mode-specific variables, such as
+ \l{#QMAKE_LFLAGS_RELEASE}{QMAKE_LFLAGS_RELEASE}, instead of general
+ variables, such as \l{#QMAKE_LFLAGS}{QMAKE_LFLAGS}, where possible.
+
+ The following options define the application/library type:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o qt \o The target is a Qt application/library and requires the Qt
+ library and header files. The proper include and library paths for the
+ Qt library will automatically be added to the project. This is defined
+ by default, and can be fine-tuned with the \c{\l{#qt}{QT}} variable.
+ \row \o thread \o The target is a multi-threaded application or library. The
+ proper defines and compiler flags will automatically be added to
+ the project.
+ \row \o x11 \o The target is a X11 application or library. The proper
+ include paths and libraries will automatically be added to the
+ project.
+ \row \o windows \o The target is a Win32 window application (app only). The
+ proper include paths, compiler flags and libraries will
+ automatically be added to the project.
+ \row \o console \o The target is a Win32 console application (app only). The
+ proper include paths, compiler flags and libraries will
+ automatically be added to the
+ project.
+ \row \o shared \o{1,3} The target is a shared object/DLL. The proper
+ include paths, compiler flags and libraries will automatically be
+ added to the project.
+ \row \o dll \o
+ \row \o dylib \o
+ \row \o static \o{1,2} The target is a static library (lib only). The proper
+ compiler flags will automatically be added to the project.
+ \row \o staticlib \o
+ \row \o plugin \o The target is a plugin (lib only). This enables dll as well.
+ \row \o designer \o The target is a plugin for \QD.
+ \row \o uic3 \o Configures qmake to run uic3 on the content of \c FORMS3 if
+ defined; otherwise the contents of \c FORMS will be processed instead.
+ \row \o no_lflags_merge \o Ensures that the list of libraries stored in the
+ \c LIBS variable is not reduced to a list of unique values before it is used.
+ \row \o resources \o Configures qmake to run rcc on the content of \c RESOURCES
+ if defined.
+ \endtable
+
+ These options are used to set the compiler flags:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o 3dnow \o AMD 3DNow! instruction support is enabled.
+ \row \o exceptions \o Exception support is enabled.
+ \row \o mmx \o Intel MMX instruction support is enabled.
+ \row \o rtti \o RTTI support is enabled.
+ \row \o stl \o STL support is enabled.
+ \row \o sse \o SSE support is enabled.
+ \row \o sse2 \o SSE2 support is enabled.
+ \endtable
+
+ These options define specific features on Windows only:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o flat \o When using the vcapp template this will put all the source
+ files into the source group and the header files into the header group
+ regardless of what directory they reside in. Turning this
+ option off will group the files within the source/header group depending
+ on the directory they reside. This is turned on by default.
+ \row \o embed_manifest_dll \o Embeds a manifest file in the DLL created
+ as part of a library project.
+ \row \o embed_manifest_exe \o Embeds a manifest file in the DLL created
+ as part of an application project.
+ \row \o incremental \o Used to enable or disable incremental linking in Visual
+ C++, depending on whether this feature is enabled or disabled by default.
+ \endtable
+
+ See \l{qmake Platform Notes#Visual Studio 2005 Manifest Files}{qmake Platform Notes}
+ for more information on the options for embedding manifest files.
+
+ These options only have an effect on Mac OS X:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o ppc \o Builds a PowerPC binary.
+ \row \o x86 \o Builds an i386 compatible binary.
+ \row \o app_bundle \o Puts the executable into a bundle (this is the default).
+ \row \o lib_bundle \o Puts the library into a library bundle.
+ \endtable
+
+ The build process for bundles is also influenced by
+ the contents of the \l{#QMAKE_BUNDLE_DATA}{QMAKE_BUNDLE_DATA} variable.
+
+ These options have an effect on Linux/Unix platforms:
+
+ \table 95%
+ \header \o Option \o Description
+ \row \o largefile \o Includes support for large files.
+ \row \o separate_debug_info \o Puts debugging information for libraries in
+ separate files.
+ \endtable
+
+ The \c CONFIG variable will also be checked when resolving scopes. You may
+ assign anything to this variable.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 26
+
+ \target DEFINES
+ \section1 DEFINES
+
+ \c qmake adds the values of this variable as compiler C
+ preprocessor macros (-D option).
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 27
+
+ \target DEF_FILE
+ \section1 DEF_FILE
+
+ \e {This is only used on Windows when using the \c app template}.
+
+ Specifies a \c .def file to be included in the project.
+
+ \target DEPENDPATH
+ \section1 DEPENDPATH
+
+ This variable contains the list of all directories to look in to
+ resolve dependencies. This will be used when crawling through
+ \c included files.
+
+ \target DEPLOYMENT
+ \section1 DEPLOYMENT
+
+ \e {This is only used on Windows CE.}
+
+ Specifies which additional files will be deployed. Deployment means the
+ transfer of files from the development system to the target device or
+ emulator.
+
+ Files can be deployed by either creating a Visual Studio project or using
+ the \l {Using QTestLib remotely on Windows CE}{cetest} executable.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 28
+
+ This will upload all PNG images in \c path to the same directory your
+ build target will be deployed to.
+
+ The default deployment target path for Windows CE is
+ \c{%CSIDL_PROGRAM_FILES%\target}, which usually gets expanded to
+ \c{\Program Files\target}.
+
+ It is also possible to specify multiple \c sources to be deployed on
+ target \c paths. In addition, different variables can be used for
+ deployment to different directories.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 29
+
+ \note All linked Qt libraries will be deployed to the path specified
+ by \c{myFiles.path}.
+
+ \target DEPLOYMENT_PLUGIN
+ \section1 DEPLOYMENT_PLUGIN
+
+ \e {This is only used on Windows CE.}
+
+ This variable specifies the Qt plugins that will be deployed. All plugins
+ available in Qt can be explicitly deployed to the device. See
+ \l{Static Plugins}{Static Plugins} for a complete list.
+
+ \note No plugins will be deployed automatically. If the application
+ depends on plugins, these plugins have to be specified manually.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 128
+
+ This will upload the jpeg imageformat plugin to the plugins directory
+ on the Windows CE device.
+
+ \target DESTDIR
+ \section1 DESTDIR
+
+ Specifies where to put the \l{#TARGET}{target} file.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 30
+
+ \target DESTDIR_TARGET
+ \section1 DESTDIR_TARGET
+
+ This variable is set internally by \c qmake, which is basically the
+ \c DESTDIR variable with the \c TARGET variable appened at the end.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target DLLDESTDIR
+ \section1 DLLDESTDIR
+
+ Specifies where to copy the \l{#TARGET}{target} dll.
+
+ \target DISTFILES
+ \section1 DISTFILES
+
+ This variable contains a list of files to be included in the dist
+ target. This feature is supported by UnixMake specs only.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 31
+
+ \target DSP_TEMPLATE
+ \section1 DSP_TEMPLATE
+
+ This variable is set internally by \c qmake, which specifies where the
+ dsp template file for basing generated dsp files is stored. The value
+ of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target FORMS
+ \section1 FORMS
+
+ This variable specifies the UI files (see \link
+ designer-manual.html Qt Designer \endlink) to be processed through \c uic
+ before compiling. All dependencies, headers and source files required
+ to build these UI files will automatically be added to the project.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 32
+
+ If FORMS3 is defined in your project, then this variable must contain
+ forms for uic, and not uic3. If CONFIG contains uic3, and FORMS3 is not
+ defined, the this variable must contain only uic3 type forms.
+
+ \target FORMS3
+ \section1 FORMS3
+
+ This variable specifies the old style UI files to be processed
+ through \c uic3 before compiling, when \c CONFIG contains uic3.
+ All dependencies, headers and source files required to build these
+ UI files will automatically be added to the project.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 33
+
+ \target GUID
+ \section1 GUID
+
+ Specifies the GUID that is set inside a \c{.vcproj} file. The GUID is
+ usually randomly determined. However, should you require a fixed GUID,
+ it can be set using this variable.
+
+ This variable is specific to \c{.vcproj} files only; it is ignored
+ otherwise.
+
+ \target HEADERS
+ \section1 HEADERS
+
+ Defines the header files for the project.
+
+ \c qmake will generate dependency information (unless \c -nodepend
+ is specified on the \l{Running qmake#Commands}{command line})
+ for the specified headers. \c qmake will also automatically detect if
+ \c moc is required by the classes in these headers, and add the
+ appropriate dependencies and files to the project for generating and
+ linking the moc files.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 34
+
+ See also \l{#SOURCES}{SOURCES}.
+
+ \target INCLUDEPATH
+ \section1 INCLUDEPATH
+
+ This variable specifies the #include directories which should be
+ searched when compiling the project. Use ';' or a space as the
+ directory separator.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 35
+
+ To specify a path containing spaces, quote the path using the technique
+ mentioned in the \l{qmake Project Files#Whitespace}{qmake Project Files}
+ document. For example, paths with spaces can be specified on Windows
+ and Unix platforms by using the \l{qmake Function Reference#quote-string}{quote()}
+ function in the following way:
+
+ \snippet doc/src/snippets/qmake/spaces.pro quoting include paths with spaces
+
+ \target INSTALLS
+ \section1 INSTALLS
+
+ This variable contains a list of resources that will be installed when
+ \c{make install} or a similar installation procedure is executed. Each
+ item in the list is typically defined with attributes that provide
+ information about where it will be installed.
+
+ For example, the following \c{target.path} definition describes where the
+ build target will be installed, and the \c INSTALLS assignment adds the
+ build target to the list of existing resources to be installed:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 36
+
+ \target LEXIMPLS
+ \section1 LEXIMPLS
+
+ This variable contains a list of lex implementation files. The value
+ of this variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely
+ needs to be modified.
+
+ \target LEXOBJECTS
+ \section1 LEXOBJECTS
+
+ This variable contains the names of intermediate lex object
+ files.The value of this variable is typically handled by
+ \c qmake and rarely needs to be modified.
+
+ \target LEXSOURCES
+ \section1 LEXSOURCES
+
+ This variable contains a list of lex source files. All
+ dependencies, headers and source files will automatically be added to
+ the project for building these lex files.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 37
+
+ \target LIBS
+ \section1 LIBS
+
+ This variable contains a list of libraries to be linked into the project.
+ You can use the Unix \c -l (library) and -L (library path) flags and qmake
+ will do the correct thing with these libraries on Windows (namely this
+ means passing the full path of the library to the linker). The only
+ limitation to this is the library must exist, for qmake to find which
+ directory a \c -l lib lives in.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 38
+
+ To specify a path containing spaces, quote the path using the technique
+ mentioned in the \l{qmake Project Files#Whitespace}{qmake Project Files}
+ document. For example, paths with spaces can be specified on Windows
+ and Unix platforms by using the \l{qmake Function Reference#quote-string}{quote()}
+ function in the following way:
+
+ \snippet doc/src/snippets/qmake/spaces.pro quoting library paths with spaces
+
+ \bold{Note:} On Windows, specifying libraries with the \c{-l} option,
+ as in the above example, will cause the library with the highest version
+ number to be used; for example, \c{libmath2.lib} could potentially be used
+ instead of \c{libmathlib}. To avoid this ambiguity, we recommend that you
+ explicitly specify the library to be used by including the \c{.lib}
+ file name suffix.
+
+ By default, the list of libraries stored in \c LIBS is reduced to a list of
+ unique names before it is used. To change this behavior, add the
+ \c no_lflags_merge option to the \c CONFIG variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 39
+
+ \target LITERAL_HASH
+ \section1 LITERAL_HASH
+
+ This variable is used whenever a literal hash character (\c{#}) is needed in
+ a variable declaration, perhaps as part of a file name or in a string passed
+ to some external application.
+
+ For example:
+
+ \snippet doc/src/snippets/qmake/comments.pro 1
+
+ By using \c LITERAL_HASH in this way, the \c # character can be used
+ to construct a URL for the \c message() function to print to the console.
+
+ \target MAKEFILE
+ \section1 MAKEFILE
+
+ This variable specifies the name of the Makefile which
+ \c qmake should use when outputting the dependency information
+ for building a project. The value of this variable is typically
+ handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target MAKEFILE_GENERATOR
+ \section1 MAKEFILE_GENERATOR
+
+ This variable contains the name of the Makefile generator to use
+ when generating a Makefile. The value of this variable is typically
+ handled internally by \c qmake and rarely needs to be modified.
+
+ \target MOC_DIR
+ \section1 MOC_DIR
+
+ This variable specifies the directory where all intermediate moc
+ files should be placed.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 40
+
+ \target OBJECTS
+ \section1 OBJECTS
+
+ This variable is generated from the \link #SOURCES SOURCES
+ \endlink variable. The extension of each source file will have been
+ replaced by .o (Unix) or .obj (Win32). The value of this variable is
+ typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+ rarely needs to be modified.
+
+ \target OBJECTS_DIR
+ \section1 OBJECTS_DIR
+
+ This variable specifies the directory where all intermediate
+ objects should be placed.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 41
+
+ \target OBJMOC
+ \section1 OBJMOC
+
+ This variable is set by \c qmake if files can be found that
+ contain the Q_OBJECT macro. \c OBJMOC contains the
+ name of all intermediate moc object files. The value of this variable
+ is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \target POST_TARGETDEPS
+ \section1 POST_TARGETDEPS
+
+ All libraries that the \l{#TARGET}{target} depends on can be
+ listed in this variable. Some backends do not support this, these include
+ MSVC Dsp, and ProjectBuilder .pbproj files. Generally this is supported
+ internally by these build tools, this is useful for explicitly listing
+ dependant static libraries.
+
+ This list will go after all builtin (and \link #PRE_TARGETDEPS
+ $$PRE_TARGETDEPS \endlink) dependencies.
+
+ \target PRE_TARGETDEPS
+ \section1 PRE_TARGETDEPS
+
+ All libraries that the \l{#TARGET}{target} depends on can be
+ listed in this variable. Some backends do not support this, these include
+ MSVC Dsp, and ProjectBuilder .pbproj files. Generally this is supported
+ internally by these build tools, this is useful for explicitly listing
+ dependant static libraries.
+
+ This list will go before all builtin dependencies.
+
+ \target PRECOMPILED_HEADER
+ \section1 PRECOMPILED_HEADER
+
+ This variable indicates the header file for creating a precompiled
+ header file, to increase the compilation speed of a project.
+ Precompiled headers are currently only supported on some platforms
+ (Windows - all MSVC project types, Mac OS X - Xcode, Makefile,
+ Unix - gcc 3.3 and up).
+
+ On other platforms, this variable has different meaning, as noted
+ below.
+
+ This variable contains a list of header files that require some
+ sort of pre-compilation step (such as with moc). The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \target PWD
+ \section1 PWD
+
+ This variable contains the full path leading to the directory where
+ the \c qmake project file (project.pro) is located.
+
+ \target OUT_PWD
+ \section1 OUT_PWD
+
+ This variable contains the full path leading to the directory where
+ \c qmake places the generated Makefile.
+
+ \target QMAKE_systemvariable
+ \section1 QMAKE
+
+ This variable contains the name of the \c qmake program
+ itself and is placed in generated Makefiles. The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \target QMAKESPEC_systemvariable
+ \section1 QMAKESPEC
+
+ This variable contains the name of the \c qmake
+ configuration to use when generating Makefiles. The value of this
+ variable is typically handled by \c qmake and rarely needs to be modified.
+
+ Use the \c{QMAKESPEC} environment variable to override the \c qmake configuration.
+ Note that, due to the way \c qmake reads project files, setting the \c{QMAKESPEC}
+ environment variable from within a project file will have no effect.
+
+ \target QMAKE_APP_FLAG
+ \section1 QMAKE_APP_FLAG
+
+ This variable is empty unless the \c app
+ \l{#TEMPLATE}{TEMPLATE} is specified. The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified. Use the following instead:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 42
+
+ \target QMAKE_APP_OR_DLL
+ \section1 QMAKE_APP_OR_DLL
+
+ This variable is empty unless the \c app or \c dll
+ \l{#TEMPLATE}{TEMPLATE} is specified. The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \target QMAKE_AR_CMD
+ \section1 QMAKE_AR_CMD
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains the command for invoking the program which
+ creates, modifies and extracts archives. The value of this variable is
+ typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+ and rarely needs to be modified.
+
+ \target QMAKE_BUNDLE_DATA
+ \section1 QMAKE_BUNDLE_DATA
+
+ This variable is used to hold the data that will be installed with a library
+ bundle, and is often used to specify a collection of header files.
+
+ For example, the following lines add \c path/to/header_one.h
+ and \c path/to/header_two.h to a group containing information about the
+ headers supplied with the framework:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 43
+
+ The last line adds the information about the headers to the collection of
+ resources that will be installed with the library bundle.
+
+ Library bundles are created when the \c lib_bundle option is added to the
+ \l{#CONFIG}{CONFIG} variable.
+
+ See \l{qmake Platform Notes#Creating Frameworks}{qmake Platform Notes} for
+ more information about creating library bundles.
+
+ \e{This is used on Mac OS X only.}
+
+ \section1 QMAKE_BUNDLE_EXTENSION
+
+ This variable defines the extension to be used for library bundles.
+ This allows frameworks to be created with custom extensions instead of the
+ standard \c{.framework} directory name extension.
+
+ For example, the following definition will result in a framework with the
+ \c{.myframework} extension:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 44
+
+ \e{This is used on Mac OS X only.}
+
+ \section1 QMAKE_CC
+
+ This variable specifies the C compiler that will be used when building
+ projects containing C source code. Only the file name of the compiler
+ executable needs to be specified as long as it is on a path contained
+ in the \c PATH variable when the Makefile is processed.
+
+ \target QMAKE_CFLAGS_DEBUG
+ \section1 QMAKE_CFLAGS_DEBUG
+
+ This variable contains the flags for the C compiler in debug mode.The value of this variable is
+ typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+ and rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_MT
+ \section1 QMAKE_CFLAGS_MT
+
+ This variable contains the compiler flags for creating a
+ multi-threaded application or when the version of Qt that you link
+ against is a multi-threaded statically linked library. The value of
+ this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_MT_DBG
+ \section1 QMAKE_CFLAGS_MT_DBG
+
+ This variable contains the compiler flags for creating a debuggable
+ multi-threaded application or when the version of Qt that you link
+ against is a debuggable multi-threaded statically linked library. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_MT_DLL
+ \section1 QMAKE_CFLAGS_MT_DLL
+
+ \e {This is used on Windows only.}
+
+ This variable contains the compiler flags for creating a
+ multi-threaded dll or when the version of Qt that you link
+ against is a multi-threaded dll. The value of this variable is typically
+ handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+ rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_MT_DLLDBG
+ \section1 QMAKE_CFLAGS_MT_DLLDBG
+
+ \e {This is used on Windows only.}
+
+ This variable contains the compiler flags for creating a debuggable
+ multi-threaded dll or when the version of Qt that you link
+ against is a debuggable multi-threaded statically linked library.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_RELEASE
+ \section1 QMAKE_CFLAGS_RELEASE
+
+ This variable contains the compiler flags for creating a non-debuggable
+ application. The value of this variable is typically
+ handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+ rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_SHLIB
+ \section1 QMAKE_CFLAGS_SHLIB
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains the compiler flags for creating a shared
+ library. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CFLAGS_THREAD
+ \section1 QMAKE_CFLAGS_THREAD
+
+ This variable contains the compiler flags for creating a multi-threaded
+ application. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CFLAGS_WARN_OFF
+ \section1 QMAKE_CFLAGS_WARN_OFF
+
+ This variable is not empty if the warn_off
+ \l{#TEMPLATE}{TEMPLATE} option is specified. The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+ and rarely needs to be modified.
+
+ \target QMAKE_CFLAGS_WARN_ON
+ \section1 QMAKE_CFLAGS_WARN_ON
+
+ This variable is not empty if the warn_on
+ \l{#TEMPLATE}{TEMPLATE} option is specified.
+ The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CLEAN
+ \section1 QMAKE_CLEAN
+
+ This variable contains any files which are not generated files (such as moc and uic
+ generated files) and object files that should be removed when using "make clean".
+
+ \section1 QMAKE_CXX
+
+ This variable specifies the C++ compiler that will be used when building
+ projects containing C++ source code. Only the file name of the compiler
+ executable needs to be specified as long as it is on a path contained
+ in the \c PATH variable when the Makefile is processed.
+
+ \section1 QMAKE_CXXFLAGS
+
+ This variable contains the C++ compiler flags that are used when building
+ a project. The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified. The flags
+ specific to debug and release modes can be adjusted by modifying
+ the \c QMAKE_CXXFLAGS_DEBUG and \c QMAKE_CXXFLAGS_RELEASE variables,
+ respectively.
+
+ \target QMAKE_CXXFLAGS_DEBUG
+ \section1 QMAKE_CXXFLAGS_DEBUG
+
+ This variable contains the C++ compiler flags for creating a debuggable
+ application. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_MT
+ \section1 QMAKE_CXXFLAGS_MT
+
+ This variable contains the C++ compiler flags for creating a multi-threaded
+ application. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_MT_DBG
+ \section1 QMAKE_CXXFLAGS_MT_DBG
+
+ This variable contains the C++ compiler flags for creating a debuggable multi-threaded
+ application. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_MT_DLL
+ \section1 QMAKE_CXXFLAGS_MT_DLL
+
+ \c {This is used on Windows only.}
+
+ This variable contains the C++ compiler flags for creating a multi-threaded
+ dll. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_MT_DLLDBG
+ \section1 QMAKE_CXXFLAGS_MT_DLLDBG
+
+ \c {This is used on Windows only.}
+
+ This variable contains the C++ compiler flags for creating a multi-threaded debuggable
+ dll. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_RELEASE
+ \section1 QMAKE_CXXFLAGS_RELEASE
+
+ This variable contains the C++ compiler flags for creating an
+ application. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_SHLIB
+ \section1 QMAKE_CXXFLAGS_SHLIB
+
+ This variable contains the C++ compiler flags for creating a
+ shared library. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_THREAD
+ \section1 QMAKE_CXXFLAGS_THREAD
+
+ This variable contains the C++ compiler flags for creating a
+ multi-threaded application. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs
+ to be modified.
+
+ \target QMAKE_CXXFLAGS_WARN_OFF
+ \section1 QMAKE_CXXFLAGS_WARN_OFF
+
+ This variable contains the C++ compiler flags for suppressing compiler warnings.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_CXXFLAGS_WARN_ON
+ \section1 QMAKE_CXXFLAGS_WARN_ON
+
+ This variable contains C++ compiler flags for generating compiler warnings.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_DISTCLEAN
+ \section1 QMAKE_DISTCLEAN
+
+ This variable removes extra files upon the invocation of \c{make distclean}.
+
+ \target QMAKE_EXTENSION_SHLIB
+ \section1 QMAKE_EXTENSION_SHLIB
+
+ This variable contains the extention for shared libraries. The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+ and rarely needs to be modified.
+
+ Note that platform-specific variables that change the extension will override
+ the contents of this variable.
+
+ \section1 QMAKE_EXT_MOC
+
+ This variable changes the extention used on included moc files.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+ \section1 QMAKE_EXT_UI
+
+ This variable changes the extention used on /e Designer UI files.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+ \section1 QMAKE_EXT_PRL
+
+ This variable changes the extention used on created PRL files.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions},
+ \l{Configuring qmake's Environment#libdepend}{Library Dependencies}.
+
+ \section1 QMAKE_EXT_LEX
+
+ This variable changes the extention used on files given to lex.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions},
+ \l{#LEXSOURCES}{LEXSOURCES}.
+
+ \section1 QMAKE_EXT_YACC
+ This variable changes the extention used on files given to yacc.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions},
+ \l{#YACCSOURCES}{YACCSOURCES}.
+
+ \section1 QMAKE_EXT_OBJ
+
+ This variable changes the extention used on generated object files.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+ \section1 QMAKE_EXT_CPP
+
+ This variable changes the interpretation of all suffixes in this
+ list of values as files of type C++ source code.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+ \section1 QMAKE_EXT_H
+
+ This variable changes the interpretation of all suffixes in this
+ list of values as files of type C header files.
+
+ See also \l{Configuring qmake's Environment#Extensions}{File Extensions}.
+
+ \section1 QMAKE_EXTRA_COMPILERS
+
+ This variable contains the extra compilers/preprocessors that have been added
+
+ See also \l{Configuring qmake's Environment#Customizing}{Customizing Makefile Output}
+
+ \section1 QMAKE_EXTRA_TARGETS
+
+ This variable contains the extra targets that have been added
+
+ See also \l{Configuring qmake's Environment#Customizing}{Customizing Makefile Output}
+
+ \target QMAKE_FAILED_REQUIREMENTS
+ \section1 QMAKE_FAILED_REQUIREMENTS
+
+ This variable contains the list of requirements that were failed to be met when
+ \c qmake was used. For example, the sql module is needed and wasn't compiled into Qt. The
+ value of this variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+ and rarely needs to be modified.
+
+ \target QMAKE_FILETAGS
+ \section1 QMAKE_FILETAGS
+
+ This variable contains the file tags needed to be entered into the Makefile, such as SOURCES
+ and HEADERS. The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_FRAMEWORK_BUNDLE_NAME
+
+ In a framework project, this variable contains the name to be used for the
+ framework that is built.
+
+ By default, this variable contains the same value as the \l{#TARGET}{TARGET}
+ variable.
+
+ See \l{qmake Platform Notes#Creating Frameworks}{qmake Platform Notes} for
+ more information about creating frameworks and library bundles.
+
+ \e{This is used on Mac OS X only.}
+
+ \target QMAKE_FRAMEWORK_VERSION
+ \section1 QMAKE_FRAMEWORK_VERSION
+
+ For projects where the build target is a Mac OS X framework, this variable
+ is used to specify the version number that will be applied to the framework
+ that is built.
+
+ By default, this variable contains the same value as the \l{#VERSION}{VERSION}
+ variable.
+
+ See \l{qmake Platform Notes#Creating Frameworks}{qmake Platform Notes} for
+ more information about creating frameworks.
+
+ \e{This is used on Mac OS X only.}
+
+ \target QMAKE_INCDIR
+ \section1 QMAKE_INCDIR
+
+ This variable contains the location of all known header files to be added to
+ INCLUDEPATH when building an application. The value of this variable is
+ typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely
+ needs to be modified.
+
+ \target QMAKE_INCDIR_EGL
+ \section1 QMAKE_INCDIR_EGL
+
+ This variable contains the location of EGL header files to be added
+ to INCLUDEPATH when building an application with OpenGL/ES or
+ OpenVG support. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_INCDIR_OPENGL
+ \section1 QMAKE_INCDIR_OPENGL
+
+ This variable contains the location of OpenGL header files to be added
+ to INCLUDEPATH when building an application with OpenGL support. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ If the OpenGL implementation uses EGL (most OpenGL/ES systems),
+ then QMAKE_INCDIR_EGL may also need to be set.
+
+ \target QMAKE_INCDIR_OPENVG
+ \section1 QMAKE_INCDIR_OPENVG
+
+ This variable contains the location of OpenVG header files to be added
+ to INCLUDEPATH when building an application with OpenVG support. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ If the OpenVG implementation uses EGL then QMAKE_INCDIR_EGL may also
+ need to be set.
+
+ \target QMAKE_INCDIR_QT
+ \section1 QMAKE_INCDIR_QT
+
+ This variable contains the location of all known header file
+ paths to be added to INCLUDEPATH when building a Qt application. The value
+ of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_INCDIR_THREAD
+ \section1 QMAKE_INCDIR_THREAD
+
+ This variable contains the location of all known header file
+ paths to be added to INCLUDEPATH when building a multi-threaded application.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_INCDIR_X11
+ \section1 QMAKE_INCDIR_X11
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains the location of X11 header file paths to be
+ added to INCLUDEPATH when building a X11 application. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target QMAKE_INFO_PLIST
+ \section1 QMAKE_INFO_PLIST
+
+ \e {This is used on Mac OS X platforms only.}
+
+ This variable contains the name of the property list file, \c{.plist}, you
+ would like to include in your Mac OS X application bundle.
+
+ In the \c{.plist} file, you can define some variables, e.g., @EXECUTABLE@,
+ which qmake will replace with the actual executable name. Other variables
+ include @ICON@, @TYPEINFO@, @LIBRARY@, and @SHORT_VERSION@.
+
+ \note Most of the time, the default \c{Info.plist} is good enough.
+
+ \section1 QMAKE_LFLAGS
+
+ This variable contains a general set of flags that are passed to
+ the linker. If you need to change the flags used for a particular
+ platform or type of project, use one of the specialized variables
+ for that purpose instead of this variable.
+
+ \target QMAKE_LFLAGS_CONSOLE
+ \section1 QMAKE_LFLAGS_CONSOLE
+
+ \e {This is used on Windows only.}
+
+ This variable contains link flags when building console
+ programs. The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_CONSOLE_DLL
+
+ \e {This is used on Windows only.}
+
+ This variable contains link flags when building console
+ dlls. The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_DEBUG
+
+ This variable contains link flags when building debuggable applications. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_PLUGIN
+
+ This variable contains link flags when building plugins. The value
+ of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_QT_DLL
+
+ This variable contains link flags when building programs that
+ use the Qt library built as a dll. The value of this variable is
+ typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_RELEASE
+
+ This variable contains link flags when building applications for
+ release. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_SHAPP
+
+ This variable contains link flags when building applications which are using
+ the \c app template. The value of this variable is typically handled by
+ \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_SHLIB
+
+ This variable contains link flags when building shared libraries
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_SONAME
+
+ This variable specifies the link flags to set the name of shared objects,
+ such as .so or .dll. The value of this variable is typically handled by \c
+ qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_THREAD
+
+ This variable contains link flags when building multi-threaded projects.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_WINDOWS
+
+ \e {This is used on Windows only.}
+
+ This variable contains link flags when building Windows GUI projects
+ (i.e. non-console applications).
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LFLAGS_WINDOWS_DLL
+
+ \e {This is used on Windows only.}
+
+ This variable contains link flags when building Windows DLL projects.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBDIR
+
+ This variable contains the location of all known library
+ directories.The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBDIR_FLAGS
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains the location of all library
+ directory with -L prefixed. The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBDIR_EGL
+
+ This variable contains the location of the EGL library
+ directory, when EGL is used with OpenGL/ES or OpenVG. The value
+ of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBDIR_OPENGL
+
+ This variable contains the location of the OpenGL library
+ directory.The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ If the OpenGL implementation uses EGL (most OpenGL/ES systems),
+ then QMAKE_LIBDIR_EGL may also need to be set.
+
+ \section1 QMAKE_LIBDIR_OPENVG
+
+ This variable contains the location of the OpenVG library
+ directory. The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ If the OpenVG implementation uses EGL, then QMAKE_LIBDIR_EGL
+ may also need to be set.
+
+ \section1 QMAKE_LIBDIR_QT
+
+ This variable contains the location of the Qt library
+ directory.The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBDIR_X11
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains the location of the X11 library
+ directory.The value of this variable is typically handled by
+ \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS
+
+ This variable contains all project libraries. The value of this
+ variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_CONSOLE
+
+ \e {This Windows-specific variable is no longer used.}
+
+ Prior to Qt 4.2, this variable was used to list the libraries
+ that should be linked against when building a console application
+ project on Windows. \l{#QMAKE_LIBS_WINDOW}{QMAKE_LIBS_WINDOW}
+ should now be used instead.
+
+ \section1 QMAKE_LIBS_EGL
+
+ This variable contains all EGL libraries when building Qt with
+ OpenGL/ES or OpenVG. The value of this variable is typically
+ handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely
+ needs to be modified. The usual value is \c{-lEGL}.
+
+ \section1 QMAKE_LIBS_OPENGL
+
+ This variable contains all OpenGL libraries. The value of this
+ variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ If the OpenGL implementation uses EGL (most OpenGL/ES systems),
+ then QMAKE_LIBS_EGL may also need to be set.
+
+ \section1 QMAKE_LIBS_OPENGL_QT
+
+ This variable contains all OpenGL Qt libraries.The value of this
+ variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_OPENVG
+
+ This variable contains all OpenVG libraries. The value of this
+ variable is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf}
+ and rarely needs to be modified. The usual value is \c{-lOpenVG}.
+
+ Some OpenVG engines are implemented on top of OpenGL. This will
+ be detected at configure time and QMAKE_LIBS_OPENGL will be implicitly
+ added to QMAKE_LIBS_OPENVG wherever the OpenVG libraries are linked.
+
+ If the OpenVG implementation uses EGL, then QMAKE_LIBS_EGL may also
+ need to be set.
+
+ \section1 QMAKE_LIBS_QT
+
+ This variable contains all Qt libraries.The value of this
+ variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_QT_DLL
+
+ \e {This is used on Windows only.}
+
+ This variable contains all Qt libraries when Qt is built as a dll. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_QT_OPENGL
+
+ This variable contains all the libraries needed to link against if
+ OpenGL support is turned on. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_QT_THREAD
+
+ This variable contains all the libraries needed to link against if
+ thread support is turned on. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_RT
+
+ \e {This is used with Borland compilers only.}
+
+ This variable contains the runtime library needed to link against when
+ building an application. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_RTMT
+
+ \e {This is used with Borland compilers only.}
+
+ This variable contains the runtime library needed to link against when
+ building a multi-threaded application. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_THREAD
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains all libraries that need to be linked against
+ when building a multi-threaded application. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_WINDOWS
+
+ \e {This is used on Windows only.}
+
+ This variable contains all windows libraries.The value of this
+ variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_X11
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains all X11 libraries.The value of this
+ variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIBS_X11SM
+
+ \e {This is used on Unix platforms only.}
+
+ This variable contains all X11 session management libraries. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LIB_FLAG
+
+ This variable is not empty if the \c lib template is specified. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_LINK_SHLIB_CMD
+
+ This variable contains the command to execute when creating a
+ shared library. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_POST_LINK
+
+ This variable contains the command to execute after linking the TARGET
+ together. This variable is normally empty and therefore nothing is
+ executed, additionally some backends will not support this - mostly only
+ Makefile backends.
+
+ \section1 QMAKE_PRE_LINK
+
+ This variable contains the command to execute before linking the TARGET
+ together. This variable is normally empty and therefore nothing is
+ executed, additionally some backends will not support this - mostly only
+ Makefile backends.
+
+ \section1 QMAKE_LN_SHLIB
+
+ This variable contains the command to execute when creating a link
+ to a shared library. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_MAC_SDK
+
+ This variable is used on Mac OS X when building universal binaries.
+ This process is described in more detail in the
+ \l{Deploying an Application on Mac OS X#Architecture Dependencies}{Deploying
+ an Application on Mac OS X} document.
+
+ \section1 QMAKE_MACOSX_DEPLOYMENT_TARGET
+ This variable only has an effect when building on Mac OS X. On that
+ platform, the variable will be forwarded to the MACOSX_DEPLOYMENT_TARGET
+ environment variable, which is interpreted by the compiler or linker.
+ For more information, see the
+ \l{Deploying an Application on Mac OS X#Mac OS X Version Dependencies}{Deploying
+ an Application on Mac OS X} document.
+
+ \section1 QMAKE_MAKEFILE
+
+ This variable contains the name of the Makefile to create. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_MOC_SRC
+
+ This variable contains the names of all moc source files to
+ generate and include in the project. The value of this variable is
+ typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_QMAKE
+
+ This variable contains the location of qmake if it is not in the path.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_QT_DLL
+
+ This variable is not empty if Qt was built as a dll. The
+ value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_RESOURCE_FLAGS
+
+ This variable is used to customize the list of options passed to the
+ \l{rcc}{Resource Compiler} in each of the build rules where it is used.
+ For example, the following line ensures that the \c{-threshold} and
+ \c{-compress} options are used with particular values each time that
+ \c rcc is invoked:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 45
+
+ \section1 QMAKE_RUN_CC
+
+ This variable specifies the individual rule needed to build an object.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_RUN_CC_IMP
+
+ This variable specifies the individual rule needed to build an object.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_RUN_CXX
+
+ This variable specifies the individual rule needed to build an object.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_RUN_CXX_IMP
+
+ This variable specifies the individual rule needed to build an object.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_TARGET
+
+ This variable contains the name of the project target. The value of
+ this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 QMAKE_UIC
+
+ This variable contains the location of uic if it is not in the path.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ It can be used to specify arguments to uic as well, such as additional plugin
+ paths. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 46
+
+ \section1 QT
+
+ The values stored in the \c QT variable control which of the Qt modules are
+ used by your project.
+
+ The table below shows the options that can be used with the \c QT variable
+ and the features that are associated with each of them:
+
+ \table
+ \header \o Option \o Features
+ \row \o core (included by default) \o QtCore module
+ \row \o gui (included by default) \o QtGui module
+ \row \o network \o QtNetwork module
+ \row \o opengl \o QtOpenGL module
+ \row \o phonon \o Phonon Multimedia Framework
+ \row \o sql \o QtSql module
+ \row \o svg \o QtSvg module
+ \row \o xml \o QtXml module
+ \row \o webkit \o WebKit integration
+ \row \o qt3support \o Qt3Support module
+ \endtable
+
+ By default, \c QT contains both \c core and \c gui, ensuring that standard
+ GUI applications can be built without further configuration.
+
+ If you want to build a project \e without the QtGui module, you need to
+ exclude the \c gui value with the "-=" operator; the following line will
+ result in a minimal Qt project being built:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 47
+
+ Note that adding the \c opengl option to the \c QT variable automatically
+ causes the equivalent option to be added to the \c CONFIG variable.
+ Therefore, for Qt applications, it is not necessary to add the \c opengl
+ option to both \c CONFIG and \c{QT}.
+
+ \section1 QTPLUGIN
+
+ This variable contains a list of names of static plugins that are to be
+ compiled with an application so that they are available as built-in
+ resources.
+
+ \target QT_VERSION
+ \section1 QT_VERSION
+
+ This variable contains the current version of Qt.
+
+ \target QT_MAJOR_VERSION
+ \section1 QT_MAJOR_VERSION
+
+ This variable contains the current major version of Qt.
+
+ \target QT_MINOR_VERSION
+ \section1 QT_MINOR_VERSION
+
+ This variable contains the current minor version of Qt.
+
+ \target QT_PATCH_VERSION
+ \section1 QT_PATCH_VERSION
+
+ This variable contains the current patch version of Qt.
+
+ \section1 RC_FILE
+
+ This variable contains the name of the resource file for the application.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target RCC_DIR
+ \section1 RCC_DIR
+
+ This variable specifies the directory where all intermediate
+ resource files should be placed.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 48
+
+ \target REQUIRES
+ \section1 REQUIRES
+
+ This is a special variable processed by \c qmake. If the
+ contents of this variable do not appear in CONFIG by the time this
+ variable is assigned, then a minimal Makefile will be generated that
+ states what dependencies (the values assigned to REQUIRES) are
+ missing.
+
+ This is mainly used in Qt's build system for building the examples.
+
+ \section1 RESOURCES
+
+ This variable contains the name of the resource collection file (qrc)
+ for the application. Further information about the resource collection
+ file can be found at \l{The Qt Resource System}.
+
+ \section1 RES_FILE
+
+ This variable contains the name of the resource file for the application.
+ The value of this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target SIGNATURE_FILE
+ \section1 SIGNATURE_FILE
+
+ \e {This is only used on Windows CE.}
+
+ Specifies which signature file should be used to sign the project target.
+
+ \note This variable will overwrite the setting you have specified in configure,
+ with the \c -signature option.
+
+ \target SOURCES
+ \section1 SOURCES
+
+ This variable contains the name of all source files in the project.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 49
+
+ See also \l{#HEADERS}{HEADERS}
+
+ \section1 SRCMOC
+
+ This variable is set by \c qmake if files can be found that
+ contain the Q_OBJECT macro. \c SRCMOC contains the
+ name of all the generated moc files. The value of this variable
+ is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \target SUBDIRS
+ \section1 SUBDIRS
+
+ This variable, when used with the \l{#TEMPLATE}{\c subdirs template}
+ contains the names of all subdirectories that contain parts of the project
+ that need be built. Each subdirectory must contain its own project file.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 50
+
+ It is essential that the project file in each subdirectory has the same
+ name as the subdirectory itself, so that \c qmake can find it.
+ For example, if the subdirectory is called \c myapp then the project file
+ in that directory should be called \c myapp.pro.
+
+ If you need to ensure that the subdirectories are built in the order in
+ which they are specified, update the \l{#CONFIG}{CONFIG} variable to
+ include the \c ordered option:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 51
+
+ \target TARGET
+ \section1 TARGET
+
+ This specifies the name of the target file.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 52
+
+ The project file above would produce an executable named \c myapp on
+ unix and 'myapp.exe' on windows.
+
+ \section1 TARGET_EXT
+
+ This variable specifies the target's extension. The value of this variable
+ is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \section1 TARGET_x
+
+ This variable specifies the target's extension with a major version number. The value of this variable
+ is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \section1 TARGET_x.y.z
+
+ This variable specifies the target's extension with version number. The value of this variable
+ is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \target TEMPLATE
+ \section1 TEMPLATE
+
+ This variable contains the name of the template to use when
+ generating the project. The allowed values are:
+
+ \table
+ \header \o Option \o Description
+ \row \o app \o Creates a Makefile for building applications (the default). (See
+ \l{qmake Common Projects#Application}{qmake Common Projects} for more information.)
+ \row \o lib \o Creates a Makefile for building libraries. (See
+ \l{qmake Common Projects#Library}{qmake Common Projects} for more information.)
+ \row \o subdirs \o Creates a Makefile for building targets in subdirectories.
+ The subdirectories are specified using the \l{#SUBDIRS}{SUBDIRS}
+ variable.
+ \row \o vcapp \o \e {Windows only} Creates an application project for Visual Studio.
+ (See \l{qmake Platform Notes#Creating Visual Studio Project Files}{qmake Platform Notes}
+ for more information.)
+ \row \o vclib \o \e {Windows only} Creates a library project for Visual Studio.
+ (See \l{qmake Platform Notes#Creating Visual Studio Project Files}{qmake Platform Notes}
+ for more information.)
+ \endtable
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 53
+
+ The template can be overridden by specifying a new template type with the
+ \c -t command line option. This overrides the template type \e after the .pro
+ file has been processed. With .pro files that use the template type to
+ determine how the project is built, it is necessary to declare TEMPLATE on
+ the command line rather than use the \c -t option.
+
+ \section1 TRANSLATIONS
+
+ This variable contains a list of translation (.ts) files that contain
+ translations of the user interface text into non-native languages.
+
+ See the \l{Qt Linguist Manual} for more information about
+ internationalization (i18n) and localization (l10n) with Qt.
+
+ \section1 UICIMPLS
+
+ This variable contains a list of the generated implementation files by UIC.
+ The value of this variable
+ is typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and rarely needs to be
+ modified.
+
+ \section1 UICOBJECTS
+
+ This variable is generated from the UICIMPLS variable. The extension of each
+ file will have been replaced by .o (Unix) or .obj (Win32). The value of this variable is
+ typically handled by \c qmake or \l{#QMAKESPEC}{qmake.conf} and
+ rarely needs to be modified.
+
+ \target UI_DIR
+ \section1 UI_DIR
+
+ This variable specifies the directory where all intermediate files from uic
+ should be placed. This variable overrides both UI_SOURCES_DIR and
+ UI_HEADERS_DIR.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 54
+
+ \target UI_HEADERS_DIR
+ \section1 UI_HEADERS_DIR
+
+ This variable specifies the directory where all declaration files (as
+ generated by uic) should be placed.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 55
+
+ \target UI_SOURCES_DIR
+ \section1 UI_SOURCES_DIR
+
+ This variable specifies the directory where all implementation files (as generated
+ by uic) should be placed.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 56
+
+ \target VERSION
+ \section1 VERSION
+
+ This variable contains the version number of the application or library if
+ either the \c app \l{#TEMPLATE}{TEMPLATE} or the \c lib \l{#TEMPLATE}{TEMPLATE}
+ is specified.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 57
+
+ \section1 VER_MAJ
+
+ This variable contains the major version number of the library, if the
+ \c lib \l{#TEMPLATE}{template} is specified.
+
+ \section1 VER_MIN
+
+ This variable contains the minor version number of the library, if the
+ \c lib \l{#TEMPLATE}{template} is specified.
+
+ \section1 VER_PAT
+
+ This variable contains the patch version number of the library, if the
+ \c lib \l{#TEMPLATE}{template} is specified.
+
+ \section1 VPATH
+
+ This variable tells \c qmake where to search for files it cannot
+ open. With this you may tell \c qmake where it may look for things
+ like SOURCES, and if it finds an entry in SOURCES that cannot be
+ opened it will look through the entire VPATH list to see if it can
+ find the file on its own.
+
+ See also \l{#DEPENDPATH}{DEPENDPATH}.
+
+ \section1 YACCIMPLS
+
+ This variable contains a list of yacc source files. The value of
+ this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \section1 YACCOBJECTS
+
+ This variable contains a list of yacc object files. The value of
+ this variable is typically handled by \c qmake or
+ \l{#QMAKESPEC}{qmake.conf} and rarely needs to be modified.
+
+ \target YACCSOURCES
+ \section1 YACCSOURCES
+
+ This variable contains a list of yacc source files to be included
+ in the project. All dependencies, headers and source files will
+ automatically be included in the project.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 58
+
+ \section1 _PRO_FILE_
+
+ This variable contains the path to the project file in use.
+
+ For example, the following line causes the location of the project
+ file to be written to the console:
+
+ \snippet doc/src/snippets/qmake/project_location.pro project file
+
+ \section1 _PRO_FILE_PWD_
+
+ This variable contains the path to the directory containing the project
+ file in use.
+
+ For example, the following line causes the location of the directory
+ containing the project file to be written to the console:
+
+ \snippet doc/src/snippets/qmake/project_location.pro project file directory
+*/
+
+/*!
+ \page qmake-function-reference.html
+ \title qmake Function Reference
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Variable Reference
+ \nextpage Configuring qmake's Environment
+
+ \c qmake provides built-in functions to allow the contents of
+ variables to be processed, and to enable tests to be performed
+ during the configuration process. Functions that process the
+ contents of variables typically return values that can be assigned
+ to other variables, and these values are obtained by prefixing
+ function with the \c $$ operator. Functions that perform tests
+ are usually used as the conditional parts of scopes; these are
+ indicated in the function descriptions below.
+
+ \tableofcontents{2}
+
+ \section1 basename(variablename)
+
+ Returns the basename of the file specified. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 59
+
+ \section1 CONFIG(config)
+ [Conditional]
+
+ This function can be used to test for variables placed into the
+ \c CONFIG variable. This is the same as regular old style (tmake) scopes,
+ but has the added advantage a second parameter can be passed to test for
+ the active config. As the order of values is important in \c CONFIG
+ variables (i.e. the last one set will be considered the active config for
+ mutually exclusive values) a second parameter can be used to specify a set
+ of values to consider. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 60
+
+ Because release is considered the active setting (for feature parsing)
+ it will be the CONFIG used to generate the build file. In the common
+ case a second parameter is not needed, but for specific mutual
+ exclusive tests it is invaluable.
+
+ \section1 contains(variablename, value)
+ [Conditional]
+
+ Succeeds if the variable \e variablename contains the value \e value;
+ otherwise fails. You can check the return value of this function using
+ a scope.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 61
+
+ The contents of the scope are only processed if the \c drivers
+ variable contains the value, \c network. If this is the case, the
+ appropriate files are added to the \c SOURCES and \c HEADERS
+ variables.
+
+ \section1 count(variablename, number)
+ [Conditional]
+
+ Succeeds if the variable \e variablename contains a list with the
+ specified \e number of value; otherwise fails.
+
+ This function is used to ensure that declarations inside a scope are
+ only processed if the variable contains the correct number of values;
+ for example:
+
+ \snippet doc/src/snippets/qmake/functions.pro 2
+
+ \section1 dirname(file)
+
+ Returns the directory name part of the specified file. For example:
+
+ \snippet doc/src/snippets/qmake/dirname.pro 0
+
+ \section1 error(string)
+
+ This function never returns a value. \c qmake displays the given
+ \e string to the user, and exits. This function should only be used
+ for unrecoverable errors.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 62
+
+ \section1 eval(string)
+ [Conditional]
+
+ Evaluates the contents of the string using \c qmake's syntax rules
+ and returns true.
+ Definitions and assignments can be used in the string to modify the
+ values of existing variables or create new definitions.
+
+ For example:
+ \snippet doc/src/snippets/qmake/functions.pro 4
+
+ Note that quotation marks can be used to delimit the string, and that
+ the return value can be discarded if it is not needed.
+
+ \section1 exists(filename)
+ [Conditional]
+
+ Tests whether a file with the given \e filename exists.
+ If the file exists, the function succeeds; otherwise it fails.
+ If a regular expression is specified for the filename, this function
+ succeeds if any file matches the regular expression specified.
+
+ For example:
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 63
+
+ Note that "/" can be used as a directory separator, regardless of the
+ platform in use.
+
+ \section1 find(variablename, substr)
+
+ Places all the values in \e variablename that match \e substr. \e
+ substr may be a regular expression, and will be matched accordingly.
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 64
+
+ MY_VAR2 will contain '-Lone -Ltwo -Lthree -Lfour -Lfive', and MY_VAR3 will
+ contains 'three two three'.
+
+ \section1 for(iterate, list)
+
+ This special test function will cause a loop to be started that
+ iterates over all values in \e list, setting \e iterate to each
+ value in turn. As a convenience, if \e list is 1..10 then iterate will
+ iterate over the values 1 through 10.
+
+ The use of an else scope afer a condition line with a for() loop is
+ disallowed.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 65
+
+ \section1 include(filename)
+ [Conditional]
+
+ Includes the contents of the file specified by \e filename into the
+ current project at the point where it is included. This function
+ succeeds if \e filename is included; otherwise it fails. The included
+ file is processed immediately.
+
+ You can check whether the file was included by using this function as
+ the condition for a scope; for example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 66
+
+ \section1 infile(filename, var, val)
+ [Conditional]
+
+ Succeeds if the file \e filename (when parsed by \c qmake itself)
+ contains the variable \e var with a value of \e val; otherwise fails.
+ If you do not specify a third argument (\e val), the function will
+ only test whether \e var has been declared in the file.
+
+ \section1 isEmpty(variablename)
+ [Conditional]
+
+ Succeeds if the variable \e variablename is empty; otherwise fails.
+ This is the equivalent of \c{count( variablename, 0 )}.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 67
+
+ \section1 join(variablename, glue, before, after)
+
+ Joins the value of \e variablename with \c glue. If this value is
+ non-empty it prefixes the value with \e before and suffix it with \e
+ after. \e variablename is the only required field, the others default
+ to empty strings. If you need to encode spaces in \e glue, \e before, or \e
+ after you must quote them.
+
+ \section1 member(variablename, position)
+
+ Returns the value at the given \e position in the list of items in
+ \e variablename.
+ If an item cannot be found at the position specified, an empty string is
+ returned. \e variablename is the only required field. If not specified,
+ \c position defaults to 0, causing the first value in the list to be
+ returned.
+
+ \section1 message(string)
+
+ This function simply writes a message to the console. Unlike the
+ \c error() function, this function allows processing to continue.
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 68
+
+ The above line causes "This is a message" to be written to the console.
+ The use of quotation marks is optional.
+
+ \note By default, messages are written out for each Makefile generated by
+ qmake for a given project. If you want to ensure that messages only appear
+ once for each project, test the \c build_pass variable
+ \l{qmake Advanced Usage}{in conjunction with a scope} to filter out
+ messages during builds; for example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 69
+
+ \section1 prompt(question)
+
+ Displays the specified \e question, and returns a value read from stdin.
+
+ \section1 quote(string)
+
+ Converts a whole \e string into a single entity and returns the result.
+ Newlines, carriage returns, and tabs can be specified in the string
+ with \\n \\r and \\t. The return value does not contain either single
+ or double quotation marks unless you explicitly include them yourself,
+ but will be placed into a single entry (for literal expansion).
+
+ \section1 replace(string, old_string, new_string)
+
+ Replaces each instance of \c old_string with \c new_string in the
+ contents of the variable supplied as \c string. For example, the
+ code
+
+ \snippet doc/src/snippets/qmake/replace.pro 0
+
+ prints the message:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 70
+
+ \section1 sprintf(string, arguments...)
+
+ Replaces %1-%9 with the arguments passed in the comma-separated list
+ of function \e arguments and returns the processed string.
+
+ \section1 system(command)
+ [Conditional]
+
+ Executes the given \c command in a secondary shell, and succeeds
+ if the command returns with a zero exit status; otherwise fails.
+ You can check the return value of this function using a scope:
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 71
+
+ Alternatively, you can use this function to obtain stdout and stderr
+ from the command, and assign it to a variable. For example, you can
+ use this to interrogate information about the platform:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 72
+
+ \target unique
+ \section1 unique(variablename)
+
+ This will return a list of values in variable that are unique (that is
+ with repetitive entries removed). For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 73
+
+ \section1 warning(string)
+
+ This function will always succeed, and will display the given
+ \e string to the user. message() is a synonym for warning().
+*/
+
+/*!
+ \page qmake-environment-reference.html
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Function Reference
+
+ \title Configuring qmake's Environment
+
+ \tableofcontents
+
+ \target Properties
+ \section1 Properties
+
+ \c qmake has a system of persistant information, this allows you to
+ \c set a variable in qmake once, and each time qmake is invoked this
+ value can be queried. Use the following to set a property in qmake:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 74
+
+ The appropriate variable and value should be substituted for
+ \c VARIABLE and \c VALUE.
+
+ To retrieve this information back from qmake you can do:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 75
+
+ \note \c{qmake -query} will only list variables that you have
+ previously set with \c{qmake -set VARIABLE VALUE}.
+
+ This information will be saved into a QSettings object (meaning it
+ will be stored in different places for different platforms). As
+ \c VARIABLE is versioned as well, you can set one value in an older
+ version of \c qmake, and newer versions will retrieve this value. However,
+ if you set \c VARIABLE for a newer version of \c qmake, the older version
+ will not use this value. You can however query a specific version of a
+ variable if you prefix that version of \c qmake to \c VARIABLE, as in
+ the following example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 76
+
+ \c qmake also has the notion of \c builtin properties, for example you can
+ query the installation of Qt for this version of \c qmake with the
+ \c QT_INSTALL_PREFIX property:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 77
+
+ These built-in properties cannot have a version prefixed to them as
+ they are not versioned, and each version of \c qmake will have its own
+ built-in set of these values. The list below outlines the built-in
+ properties:
+
+ \list
+ \o \c QT_INSTALL_PREFIX - Where the version of Qt this qmake is built for resides
+ \o \c QT_INSTALL_DATA - Where data for this version of Qt resides
+ \o \c QMAKE_VERSION - The current version of qmake
+ \endlist
+
+ Finally, these values can be queried in a project file with a special
+ notation such as:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 78
+
+ \target QMAKESPEC
+ \section1 QMAKESPEC
+
+ \c qmake requires a platform and compiler description file which
+ contains many default values used to generate appropriate Makefiles.
+ The standard Qt distribution comes with many of these files, located
+ in the \c mkspecs subdirectory of the Qt installation.
+
+ The \c QMAKESPEC environment variable can contain any of the following:
+
+ \list
+ \o A complete path to a directory containing a \c{qmake.conf} file.
+ In this case \c qmake will open the \c{qmake.conf} file from within that
+ directory. If the file does not exist, \c qmake will exit with an
+ error.
+ \o The name of a platform-compiler combination. In this case, \c qmake
+ will search in the directory specified by the \c mkspecs subdirectory
+ of the data path specified when Qt was compiled (see
+ QLibraryInfo::DataPath).
+ \endlist
+
+ \bold{Note:} The \c QMAKESPEC path will automatically be added to the
+ \l{qmake Variable Reference#INCLUDEPATH}{INCLUDEPATH} system variable.
+
+ \target INSTALLS
+ \section1 INSTALLS
+
+ It is common on Unix to also use the build tool to install applications
+ and libraries; for example, by invoking \c{make install}. For this reason,
+ \c qmake has the concept of an install set, an object which contains
+ instructions about the way part of a project is to be installed.
+ For example, a collection of documentation files can be described in the
+ following way:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 79
+
+ The \c path member informs \c qmake that the files should be installed in
+ \c /usr/local/program/doc (the path member), and the \c files member
+ specifies the files that should be copied to the installation directory.
+ In this case, everything in the \c docs directory will be coped to
+ \c /usr/local/program/doc.
+
+ Once an install set has been fully described, you can append it to the
+ install list with a line like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 80
+
+ \c qmake will ensure that the specified files are copied to the installation
+ directory. If you require greater control over this process, you can also
+ provide a definition for the \c extra member of the object. For example,
+ the following line tells \c qmake to execute a series of commands for this
+ install set:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 81
+
+ The \c unix scope
+ (see \l{qmake Advanced Usage#Scopes and Conditions}{Scopes and Conditions})
+ ensures that these particular commands are only executed on Unix platforms.
+ Appropriate commands for other platforms can be defined using other scope
+ rules.
+
+ Commands specified in the \c extra member are executed before the instructions
+ in the other members of the object are performed.
+
+ If you append a built-in install set to the \c INSTALLS variable and do
+ not specify \c files or \c extra members, \c qmake will decide what needs to
+ be copied for you. Currently, the only supported built-in install set is
+ \c target:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 82
+
+ In the above lines, \c qmake knows what needs to be copied, and will handle
+ the installation process automatically.
+
+ \target cache
+ \section1 Cache File
+
+ The cache file is a special file \c qmake reads to find settings not specified
+ in the \c qmake.conf file, project files, or at the command line. If
+ \c -nocache is not specified when \c qmake is run, it will try to find a file
+ called \c{.qmake.cache} in parent directories of the current directory. If
+ it fails to find this file, it will silently ignore this step of processing.
+
+ If it finds a \c{.qmake.cache} file then it will process this file first before
+ it processes the project file.
+
+ \target LibDepend
+ \section1 Library Dependencies
+
+ Often when linking against a library, \c qmake relies on the underlying
+ platform to know what other libraries this library links against, and
+ lets the platform pull them in. In many cases, however, this is not
+ sufficent. For example, when statically linking a library, no other
+ libraries are linked to, and therefore no dependencies to those
+ libraries are created. However, an application that later links
+ against this library will need to know where to find the symbols that
+ the static library will require. To help with this situation, \c qmake
+ attempts to follow a library's dependencies where appropriate, but
+ this behavior must be explicitly enabled by following two steps.
+
+ The first step is to enable dependency tracking in the library itself.
+ To do this you must tell \c qmake to save information about the library:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 83
+
+ This is only relevant to the \c lib template, and will be ignored for
+ all others. When this option is enabled, \c qmake will create a file
+ ending in .prl which will save some meta-information about the
+ library. This metafile is just like an ordinary project file, but only
+ contains internal variable declarations. You are free to view this file
+ and, if it is deleted, \c qmake will know to recreate it when necessary,
+ either when the project file is later read, or if a dependent library
+ (described below) has changed. When installing this library, by
+ specifying it as a target in an \c INSTALLS declaration, \c qmake will
+ automatically copy the .prl file to the installation path.
+
+ The second step in this process is to enable reading of this meta
+ information in the applications that use the static library:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 84
+
+ When this is enabled, \c qmake will process all libraries linked to
+ by the application and find their meta-information. \c qmake will use
+ this to determine the relevant linking information, specifically adding
+ values to the application project file's list of \c DEFINES as well as
+ \c LIBS. Once \c qmake has processed this file, it will then look through
+ the newly introduced libraries in the \c LIBS variable, and find their
+ dependent .prl files, continuing until all libraries have been resolved.
+ At this point, the Makefile is created as usual, and the libraries are
+ linked explicitlyy against the application.
+
+ The internals of the .prl file are left closed so they can easily
+ change later. They are not designed to be changed by hand, should only
+ be created by \c qmake, and should not be transferred between operating
+ systems as they may contain platform-dependent information.
+
+ \target Extensions
+ \section1 File Extensions
+
+ Under normal circumstances \c qmake will try to use appropriate file extensions
+ for your platform. However, it is sometimes necessary to override the default
+ choices for each platform and explicitly define file extensions for \c qmake to use.
+ This is achieved by redefining certain built-in variables; for example the extension
+ used for \l moc files can be redefined with the following assignment in a project
+ file:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 85
+
+ The following variables can be used to redefine common file extensions recognized
+ by \c qmake:
+
+ \list
+ \o QMAKE_EXT_MOC - This modifies the extension placed on included moc files.
+ \o QMAKE_EXT_UI - This modifies the extension used for designer UI files (usually
+ in \c FORMS).
+ \o QMAKE_EXT_PRL - This modifies the extension placed on
+ \l{#LibDepend}{library dependency files}.
+ \o QMAKE_EXT_LEX - This changes the suffix used in files (usually in \c LEXSOURCES).
+ \o QMAKE_EXT_YACC - This changes the suffix used in files (usually in \c YACCSOURCES).
+ \o QMAKE_EXT_OBJ - This changes the suffix used on generated object files.
+ \endlist
+
+ All of the above accept just the first value, so you must assign to it just one
+ value that will be used throughout your project file. There are two variables that
+ accept a list of values:
+
+ \list
+ \o QMAKE_EXT_CPP - Causes \c qmake to interpret all files with these suffixes as
+ C++ source files.
+ \o QMAKE_EXT_H - Causes \c qmake to interpret all files with these suffixes as
+ C and C++ header files.
+ \endlist
+
+ \target Customizing
+ \section1 Customizing Makefile Output
+
+ \c qmake tries to do everything expected of a cross-platform build tool.
+ This is often less than ideal when you really need to run special
+ platform-dependent commands. This can be achieved with specific instructions
+ to the different \c qmake backends.
+
+ Customization of the Makefile output is performed through an object-style
+ API as found in other places in \c qmake. Objects are defined automatically
+ by specifying their members; for example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 86
+
+ The definitions above define a \c qmake target called \c mytarget, containing
+ a Makefile target called \c{.buildfile} which in turn is generated with
+ the \c touch command. Finally, the \c{.depends} member specifies that
+ \c mytarget depends on \c mytarget2, another target that is defined afterwards.
+ \c mytarget2 is a dummy target; it is only defined to echo some text to
+ the console.
+
+ The final step is to instruct \c qmake that this object is a target to be built:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 87
+
+ This is all you need to do to actually build custom targets. Of course, you may
+ want to tie one of these targets to the
+ \l{qmake Variable Reference#TARGET}{qmake build target}. To do this, you simply need to
+ include your Makefile target in the list of
+ \l{qmake Variable Reference#PRE_TARGETDEPS}{PRE_TARGETDEPS}.
+
+ The following tables are an overview of the options available to you with the QMAKE_EXTRA_TARGETS
+ variable.
+
+ \table
+ \header
+ \o Member
+ \o Description
+ \row
+ \o commands
+ \o The commands for generating the custom build target.
+ \row
+ \o CONFIG
+ \o Specific configuration options for the custom build target. See the CONFIG table for details.
+ \row
+ \o depends
+ \o The existing build targets that the custom build target depends on.
+ \row
+ \o recurse
+ \o Specifies which sub-targets should used when creating the rules in the Makefile to call in
+ the sub-target specific Makefile. This is only used when \c recursive is set in the CONFIG.
+ \row
+ \o recurse_target
+ \o Specifies the target that should be built via the sub-target Makefile for the rule in the Makefile.
+ This adds something like $(MAKE) -f Makefile.[subtarget] [recurse_target]. This is only used when
+ \c recursive is set in the CONFIG.
+ \row
+ \o target
+ \o The file being created by the custom build target.
+ \endtable
+
+ List of members specific to the CONFIG option:
+
+ \table
+ \header
+ \o Member
+ \o Description
+ \row
+ \o recursive
+ \o Indicates that rules should be created in the Makefile and thus call
+ the relevant target inside the sub-target specific Makefile. This defaults to creating
+ an entry for each of the sub-targets.
+ \endtable
+
+ For convenience, there is also a method of customizing projects
+ for new compilers or preprocessors:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 88
+
+ With the above definitions, you can use a drop-in replacement for moc if one
+ is available. The commands is executed on all arguments given to the
+ \c NEW_HEADERS variable (from the \c input member), and the result is written
+ to the file defined by the \c output member; this file is added to the
+ other source files in the project.
+ Additionally, \c qmake will execute \c depend_command to generate dependency
+ information, and place this information in the project as well.
+
+ These commands can easily be placed into a cache file, allowing subsequent
+ project files to add arguments to \c NEW_HEADERS.
+
+ The following tables are an overview of the options available to you with the QMAKE_EXTRA_COMPILERS
+ variable.
+
+ \table
+ \header
+ \o Member
+ \o Description
+ \row
+ \o commands
+ \o The commands used for for generating the output from the input.
+ \row
+ \o CONFIG
+ \o Specific configuration options for the custom compiler. See the CONFIG table for details.
+ \row
+ \o depend_command
+ \o Specifies a command used to generate the list of dependencies for the output.
+ \row
+ \o dependency_type
+ \o Specifies the type of file the output is, if it is a known type (such as TYPE_C,
+ TYPE_UI, TYPE_QRC) then it is handled as one of those type of files.
+ \row
+ \o depends
+ \o Specifies the dependencies of the output file.
+ \row
+ \o input
+ \o The variable that contains the files that should be processed with the custom compiler.
+ \row
+ \o name
+ \o A description of what the custom compiler is doing. This is only used in some backends.
+ \row
+ \o output
+ \o The filename that is created from the custom compiler.
+ \row
+ \o output_function
+ \o Specifies a custom qmake function that is used to specify the filename to be created.
+ \row
+ \o variable_out
+ \o The variable that the files created from the output should be added to.
+ \endtable
+
+ List of members specific to the CONFIG option:
+
+ \table
+ \header
+ \o Member
+ \o Description
+ \row
+ \o combine
+ \o Indicates that all of the input files are combined into a single output file.
+ \row
+ \o target_predeps
+ \o Indicates that the output should be added to the list of PRE_TARGETDEPS.
+ \row
+ \o explicit_dependencies
+ \o The dependencies for the output only get generated from the depends member and from
+ nowhere else.
+ \row
+ \o no_link
+ \o Indicates that the output should not be added to the list of objects to be linked in
+ \endtable
+*/
+
+/*!
+ \page qmake-advanced-usage.html
+ \title qmake Advanced Usage
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Platform Notes
+ \nextpage Using Precompiled Headers
+
+ Many \c qmake project files simply describe the sources and header files used
+ by the project, using a list of \c{name = value} and \c{name += value}
+ definitions. \c qmake also provides other operators, functions, and scopes
+ that can be used to process the information supplied in variable declarations.
+ These advanced features allow Makefiles to be generated for multiple platforms
+ from a single project file.
+
+ \tableofcontents
+
+ \section1 Operators
+
+ In many project files, the assignment (\c{=}) and append (\c{+=}) operators can
+ be used to include all the information about a project. The typical pattern of
+ use is to assign a list of values to a variable, and append more values
+ depending on the result of various tests. Since \c qmake defines certain
+ variables using default values, it is sometimes necessary to use the removal
+ (\c{-=}) operator to filter out values that are not required. The following
+ operators can be used to manipulate the contents of variables.
+
+ The \c = operator assigns a value to a variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 89
+
+ The above line sets the \c TARGET variable to \c myapp. This will overwrite any
+ values previously set for \c TARGET with \c myapp.
+
+ The \c += operator appends a new value to the list of values in a variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 90
+
+ The above line appends \c QT_DLL to the list of pre-processor defines to be put
+ in the generated Makefile.
+
+ The \c -= operator removes a value from the list of values in a variable:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 91
+
+ The above line removes \c QT_DLL from the list of pre-processor defines to be
+ put in the generated Makefile.
+
+ The \c *= operator adds a value to the list of values in a variable, but only
+ if it is not already present. This prevents values from being included many
+ times in a variable. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 92
+
+ In the above line, \c QT_DLL will only be added to the list of pre-processor
+ defines if it is not already defined. Note that the
+ \l{qmake Function Reference#unique}{unique()}
+ function can also be used to ensure that a variables only contains one
+ instance of each value.
+
+ The \c ~= operator replaces any values that match a regular expression with
+ the specified value:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 93
+
+ In the above line, any values in the list that start with \c QT_D or \c QT_T are
+ replaced with \c QT.
+
+ The \c $$ operator is used to extract the contents of a variable, and can be
+ used to pass values between variables or supply them to functions:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 94
+
+ \target Scopes
+ \section1 Scopes
+
+ Scopes are similar to \c if statements in procedural programming languages.
+ If a certain condition is true, the declarations inside the scope are processed.
+
+ \section2 Syntax
+
+ Scopes consist of a condition followed by an opening brace on the same line,
+ a sequence of commands and definitions, and a closing brace on a new line:
+
+ \snippet doc/src/snippets/qmake/scopes.pro syntax
+
+ The opening brace \e{must be written on the same line as the condition}.
+ Scopes may be concatenated to include more than one condition; see below
+ for examples.
+
+ \section2 Scopes and Conditions
+
+ A scope is written as a condition followed by a series of declarations
+ contained within a pair of braces; for example:
+
+ \snippet doc/src/snippets/qmake/scopes.pro 0
+
+ The above code will add the \c paintwidget_win.cpp file to the sources listed
+ in the generated Makefile if \c qmake is used on a Windows platform.
+ If \c qmake is used on a platform other than Windows, the define will be
+ ignored.
+
+ The conditions used in a given scope can also be negated to provide an
+ alternative set of declarations that will be processed only if the
+ original condition is false. For example, suppose we want to process
+ something on all platforms \e except for Windows. We can achieve this by
+ negating the scope like this:
+
+ \snippet doc/src/snippets/qmake/scopes.pro 1
+
+ Scopes can be nested to combine more than one condition. For instance, if
+ you want to include a particular file for a certain platform only if
+ debugging is enabled then you write the following:
+
+ \snippet doc/src/snippets/qmake/scopes.pro 2
+
+ To save writing many nested scopes, you can nest scopes using the \c :
+ operator. The nested scopes in the above example can be rewritten in
+ the following way:
+
+ \snippet doc/src/snippets/qmake/scopes.pro 3
+
+ You may also use the \c : operator to perform single line conditional
+ assignments; for example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 95
+
+ The above line adds \c QT_DLL to the \c DEFINES variable only on the
+ Windows platform.
+ Generally, the \c : operator behaves like a logical AND operator, joining
+ together a number of conditions, and requiring all of them to be true.
+
+ There is also the \c | operator to act like a logical OR operator, joining
+ together a number of conditions, and requiring only one of them to be true.
+
+ \snippet doc/src/snippets/qmake/scopes.pro 4
+
+ You can also provide alternative declarations to those within a scope by
+ using an \c else scope. Each \c else scope is processed if the conditions
+ for the preceding scopes are false.
+ This allows you to write complex tests when combined with other scopes
+ (separated by the \c : operator as above). For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 96
+
+ \section2 Configuration and Scopes
+
+ The values stored in the
+ \l{qmake-project-files.html#GeneralConfiguration}{\c CONFIG variable}
+ are treated specially by \c qmake. Each of the possible values can be
+ used as the condition for a scope. For example, the list of values
+ held by \c CONFIG can be extended with the \c opengl value:
+
+ \snippet doc/src/snippets/qmake/configscopes.pro 0
+
+ As a result of this operation, any scopes that test for \c opengl will
+ be processed. We can use this feature to give the final executable an
+ appropriate name:
+
+ \snippet doc/src/snippets/qmake/configscopes.pro 1
+ \snippet doc/src/snippets/qmake/configscopes.pro 2
+ \snippet doc/src/snippets/qmake/configscopes.pro 3
+
+ This feature makes it easy to change the configuration for a project
+ without losing all the custom settings that might be needed for a specific
+ configuration. In the above code, the declarations in the first scope are
+ processed, and the final executable will be called \c application-gl.
+ However, if \c opengl is not specified, the declarations in the second
+ scope are processed instead, and the final executable will be called
+ \c application.
+
+ Since it is possible to put your own values on the \c CONFIG
+ line, this provides you with a convenient way to customize project files
+ and fine-tune the generated Makefiles.
+
+ \section2 Platform Scope Values
+
+ In addition to the \c win32, \c macx, and \c unix values used in many
+ scope conditions, various other built-in platform and compiler-specific
+ values can be tested with scopes. These are based on platform
+ specifications provided in Qt's \c mkspecs directory. For example, the
+ following lines from a project file show the current specification in
+ use and test for the \c linux-g++ specification:
+
+ \snippet doc/src/snippets/qmake/specifications.pro 0
+
+ You can test for any other platform-compiler combination as long as a
+ specification exists for it in the \c mkspecs directory.
+
+ \section1 Variables
+
+ Many of the variables used in project files are special variables that
+ \c qmake uses when generating Makefiles, such as \c DEFINES, \c SOURCES,
+ and \c HEADERS. It is possible for you to create variables for your own
+ use; \c qmake creates new variables with a given name when it encounters
+ an assignment to that name. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 97
+
+ There are no restricitions on what you do to your own variables, as \c
+ qmake will ignore them unless it needs to evaluate them when processing
+ a scope.
+
+ You can also assign the value of a current variable to another
+ variable by prefixing $$ to the variable name. For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 98
+
+ Now the MY_DEFINES variable contains what is in the DEFINES variable at
+ this point in the project file. This is also equivalent to:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 99
+
+ The second notation allows you to append the contents of the variable to
+ another value without separating the two with a space. For example, the
+ following will ensure that the final executable will be given a name
+ that includes the project template being used:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 100
+
+ Variables can be used to store the contents of environment variables.
+ These can be evaluated at the time that \c qmake is run, or included
+ in the generated Makefile for evaluation when the project is built.
+
+ To obtain the contents of an environment value when \c qmake is run,
+ use the \c $$(...) operator:
+
+ \snippet doc/src/snippets/qmake/environment.pro 0
+
+ In the above assignment, the value of the \c PWD environment variable
+ is read when the project file is processed.
+
+ To obtain the contents of an environment value at the time when the
+ generated Makefile is processed, use the \c $(...) operator:
+
+ \snippet doc/src/snippets/qmake/environment.pro 1
+
+ In the above assignment, the value of \c PWD is read immediately
+ when the project file is processed, but \c $(PWD) is assigned to
+ \c DESTDIR in the generated Makefile. This makes the build process
+ more flexible as long as the environment variable is set correctly
+ when the Makefile is processed.
+
+ The special \c $$[...] operator can be used to access various
+ configuration options that were set when Qt was built:
+
+ \snippet doc/src/snippets/qmake/qtconfiguration.pro 0
+
+ The variables accessible with this operator are typically used to
+ enable third party plugins and components to be integrated with Qt.
+ For example, a \QD plugin can be installed alongside \QD's built-in
+ plugins if the following declaration is made in its project file:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 101
+
+ \target VariableProcessingFunctions
+ \section1 Variable Processing Functions
+
+ \c qmake provides a selection of built-in functions to allow the
+ contents of variables to be processed. These functions process the
+ arguments supplied to them and return a value, or list of values, as
+ a result. In order to assign a result to a variable, it is necessary
+ to use the \c $$ operator with this type of function in the same way
+ used to assign contents of one variable to another:
+
+ \snippet doc/src/snippets/qmake/functions.pro 1
+
+ This type of function should be used on the right-hand side of
+ assignments (i.e, as an operand).
+
+ It is possible to define your own functions for processing the
+ contents of variables. These functions can be defined in the following
+ way:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 102
+
+ The following example function takes a variable name as its only
+ argument, extracts a list of values from the variable with the
+ \l{qmake-function-reference.html}{eval()} built-in function,
+ and compiles a list of files:
+
+ \snippet doc/src/snippets/qmake/replacefunction.pro 0
+
+ \target ConditionalFunctions
+ \section1 Conditional Functions
+
+ \c qmake provides built-in functions that can be used as conditions
+ when writing scopes. These functions do not return a value, but
+ instead indicate "success" or "failure":
+
+ \snippet doc/src/snippets/qmake/functions.pro 3
+
+ This type of function should be used in conditional expressions
+ only.
+
+ It is possible to define your own functions to provide conditions
+ for scopes. The following example tests whether each file in a list
+ exists and returns true if they all exist, or false if not:
+
+ \snippet doc/src/snippets/qmake/testfunction.pro 0
+
+ \section1 Adding New Configuration Features
+
+ \c qmake lets you create your own \e features that can be included in
+ project files by adding their names to the list of values specified by
+ the \c CONFIG variable. Features are collections of custom functions and
+ definitions in \c{.prf} files that can reside in one of many standard
+ directories. The locations of these directories are defined in a number
+ of places, and \c qmake checks each of them in the following order when
+ it looks for \c{.prf} files:
+
+ \list 1
+ \o In a directory listed in the \c QMAKEFEATURES environment variable;
+ this contains a colon-separated list of directories.
+ \o In a directory listed in the \c QMAKEFEATURES property variable; this
+ contains a colon-spearated list of directories.
+ \omit
+ \o In a features directory beneath the project's root directory (where
+ the \c{.qmake.cache} file is generated).
+ \endomit
+ \o In a features directory residing within a \c mkspecs directory.
+ \c mkspecs directories can be located beneath any of the directories
+ listed in the \c QMAKEPATH environment variable (a colon-separated list
+ of directories). (\c{$QMAKEPATH/mkspecs/<features>})
+ \o In a features directory residing beneath the directory provided by the
+ \c QMAKESPEC environment variable. (\c{$QMAKESPEC/<features>})
+ \o In a features directory residing in the \c data_install/mkspecs directory.
+ (\c{data_install/mkspecs/<features>})
+ \o In a features directory that exists as a sibling of the directory
+ specified by the \c QMAKESPEC environment variable.
+ (\c{$QMAKESPEC/../<features>})
+ \endlist
+
+ The following features directories are searched for features files:
+
+ \list 1
+ \o \c{features/unix}, \c{features/win32}, or \c{features/macx}, depending on
+ the platform in use
+ \o \c features/
+ \endlist
+
+ For example, consider the following assignment in a project file:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 103
+
+ With this addition to the \c CONFIG variable, \c qmake will search the
+ locations listed above for the \c myfeatures.prf file after it has
+ finished parsing your project file. On Unix systems, it will look for
+ the following file:
+
+ \list 1
+ \o \c $QMAKEFEATURES/myfeatures.prf (for each directory listed in the
+ \c QMAKEFEATURES environment variable)
+ \o \c $$QMAKEFEATURES/myfeatures.prf (for each directory listed in the
+ \c QMAKEFEATURES property variable)
+ \o \c myfeatures.prf (in the project's root directory)
+ \o \c $QMAKEPATH/mkspecs/features/unix/myfeatures.prf and
+ \c $QMAKEPATH/mkspecs/features/myfeatures.prf (for each directory
+ listed in the \c QMAKEPATH environment variable)
+ \o \c $QMAKESPEC/features/unix/myfeatures.prf and
+ \c $QMAKESPEC/features/myfeatures.prf
+ \o \c data_install/mkspecs/features/unix/myfeatures.prf and
+ \c data_install/mkspecs/features/myfeatures.prf
+ \o \c $QMAKESPEC/../features/unix/myfeatures.prf and
+ \c $QMAKESPEC/../features/myfeatures.prf
+ \endlist
+
+ \note The \c{.prf} files must have names in lower case.
+
+
+*/
+
+/*!
+ \page qmake-precompiledheaders.html
+ \title Using Precompiled Headers
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Advanced Usage
+ \nextpage qmake Reference
+
+ \target Introduction
+
+ Precompiled headers are a performance feature supported by some
+ compilers to compile a stable body of code, and store the compiled
+ state of the code in a binary file. During subsequent compilations,
+ the compiler will load the stored state, and continue compiling the
+ specified file. Each subsequent compilation is faster because the
+ stable code does not need to be recompiled.
+
+ \c qmake supports the use of precompiled headers (PCH) on some
+ platforms and build environments, including:
+ \list
+ \o Windows
+ \list
+ \o nmake
+ \o Dsp projects (VC 6.0)
+ \o Vcproj projects (VC 7.0 \& 7.1)
+ \endlist
+ \o Mac OS X
+ \list
+ \o Makefile
+ \o Xcode
+ \endlist
+ \o Unix
+ \list
+ \o GCC 3.4 and above
+ \endlist
+ \endlist
+
+ \target ADD_PCH
+ \section1 Adding Precompiled Headers to Your Project
+
+ \target PCH_CONTENTS
+ \section2 Contents of the Precompiled Header File
+
+ The precompiled header must contain code which is \e stable
+ and \e static throughout your project. A typical PCH might look
+ like this:
+
+ \section3 Example: \c stable.h
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 104
+
+ Note that a precompiled header file needs to separate C includes from
+ C++ includes, since the precompiled header file for C files may not
+ contain C++ code.
+
+ \target PROJECT_OPTIONS
+ \section2 Project Options
+
+ To make your project use PCH, you only need to define the
+ \c PRECOMPILED_HEADER variable in your project file:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 105
+
+ \c qmake will handle the rest, to ensure the creation and use of the
+ precompiled header file. You do not need to include the precompiled
+ header file in \c HEADERS, as \c qmake will do this if the configuration
+ supports PCH.
+
+ All platforms that support precompiled headers have the configuration
+ option \c precompile_header set. Using this option, you may trigger
+ conditional blocks in your project file to add settings when using PCH.
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 106
+
+ \section1 Notes on Possible Issues
+
+ On some platforms, the file name suffix for precompiled header files is
+ the same as that for other object files. For example, the following
+ declarations may cause two different object files with the same name to
+ be generated:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 107
+
+ To avoid potential conflicts like these, it is good practice to ensure
+ that header files that will be precompiled are given distinctive names.
+
+ \target EXAMPLE_PROJECT
+ \section1 Example Project
+
+ You can find the following source code in the
+ \c{examples/qmake/precompile} directory in the Qt distribution:
+
+ \section2 \c mydialog.ui
+
+ \quotefromfile examples/qmake/precompile/mydialog.ui
+ \printuntil
+
+ \section2 \c stable.h
+
+ \snippet examples/qmake/precompile/stable.h 0
+
+ \section2 \c myobject.h
+
+ \snippet examples/qmake/precompile/myobject.h 0
+
+ \section2 \c myobject.cpp
+
+ \snippet examples/qmake/precompile/myobject.cpp 0
+
+ \section2 \c util.cpp
+
+ \snippet examples/qmake/precompile/util.cpp 0
+
+ \section2 \c main.cpp
+
+ \snippet examples/qmake/precompile/main.cpp 0
+
+ \section2 \c precompile.pro
+
+ \snippet examples/qmake/precompile/precompile.pro 0
+*/
+
+/*!
+ \page qmake-tutorial.html
+ \title qmake Tutorial
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Manual
+ \nextpage qmake Common Projects
+
+ This tutorial teaches you how to use \c qmake. We recommend that
+ you read the \c qmake user guide after completing this tutorial.
+
+ \section1 Starting off Simple
+
+ Let's assume that you have just finished a basic implementation of
+ your application, and you have created the following files:
+
+ \list
+ \o hello.cpp
+ \o hello.h
+ \o main.cpp
+ \endlist
+
+ You will find these files in the \c{examples/qmake/tutorial} directory
+ of the Qt distribution. The only other thing you know about the setup of
+ the application is that it's written in Qt. First, using your favorite
+ plain text editor, create a file called \c hello.pro in
+ \c{examples/qmake/tutorial}. The first thing you need to do is add the
+ lines that tell \c qmake about the source and header files that are part
+ of your development project.
+
+ We'll add the source files to the project file first. To do this you
+ need to use the \l{qmake Variable Reference#SOURCES}{SOURCES} variable.
+ Just start a new line with \c {SOURCES +=} and put hello.cpp after it.
+ You should have something like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 108
+
+ We repeat this for each source file in the project, until we end up
+ with the following:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 109
+
+ If you prefer to use a Make-like syntax, with all the files listed in
+ one go you can use the newline escaping like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 110
+
+ Now that the source files are listed in the project file, the header
+ files must be added. These are added in exactly the same way as source
+ files, except that the variable name we use is
+ \l{qmake Variable Reference#HEADERS}{HEADERS}.
+
+ Once you have done this, your project file should look something like
+ this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 111
+
+ The target name is set automatically; it is the same as the project
+ file, but with the suffix appropriate to the platform. For example, if
+ the project file is called \c hello.pro, the target will be \c hello.exe
+ on Windows and \c hello on Unix. If you want to use a different name
+ you can set it in the project file:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 112
+
+ The final step is to set the \l{qmake Variable Reference#CONFIG}{CONFIG}
+ variable. Since this is a Qt application, we need to put \c qt on the
+ \c CONFIG line so that \c qmake will add the relevant libraries to be
+ linked against and ensure that build lines for \c moc and \c uic are
+ included in the generated Makefile.
+
+ The finished project file should look like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 113
+
+ You can now use \c qmake to generate a Makefile for your application.
+ On the command line, in your project's directory, type the following:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 114
+
+ Then type \c make or \c nmake depending on the compiler you use.
+
+ For Visual Studio users, \c qmake can also generate \c .dsp or
+ \c .vcproj files, for example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 115
+
+ \section1 Making an Application Debuggable
+
+ The release version of an application doesn't contain any debugging
+ symbols or other debugging information. During development it is useful
+ to produce a debugging version of the application that has the
+ relevant information. This is easily achieved by adding \c debug to the
+ \c CONFIG variable in the project file.
+
+ For example:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 116
+
+ Use \c qmake as before to generate a Makefile and you will be able to
+ obtain useful information about your application when running it in
+ a debugging environment.
+
+ \section1 Adding Platform-Specific Source Files
+
+ After a few hours of coding, you might have made a start on the
+ platform-specific part of your application, and decided to keep the
+ platform-dependent code separate. So you now have two new files to
+ include into your project file: \c hellowin.cpp and \c
+ hellounix.cpp. We can't just add these to the \c SOURCES
+ variable since this will put both files in the Makefile. So, what we
+ need to do here is to use a scope which will be processed depending on
+ which platform \c qmake is run on.
+
+ A simple scope that will add in the platform-dependent file for
+ Windows looks like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 117
+
+ So if \c qmake is run on Windows, it will add \c hellowin.cpp to the
+ list of source files. If \c qmake is run on any other platform, it
+ will simply ignore it. Now all that is left to be done is to create a
+ scope for the Unix-specific file.
+
+ When you have done that, your project file should now look
+ something like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 118
+
+ Use \c qmake as before to generate a Makefile.
+
+ \section1 Stopping qmake If a File Doesn't Exist
+
+ You may not want to create a Makefile if a certain file doesn't exist.
+ We can check if a file exists by using the exists() function. We can
+ stop \c qmake from processing by using the error() function. This
+ works in the same way as scopes do. Simply replace the scope condition
+ with the function. A check for a \c main.cpp file looks like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 119
+
+ The \c{!} symbol is used to negate the test; i.e. \c{exists( main.cpp )}
+ is true if the file exists, and \c{!exists( main.cpp )} is true if the
+ file doesn't exist.
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 120
+
+ Use \c qmake as before to generate a makefile. If you rename \c
+ main.cpp temporarily, you will see the message and \c qmake will stop
+ processing.
+
+ \section1 Checking for More than One Condition
+
+ Suppose you use Windows and you want to be able to see statement
+ output with qDebug() when you run your application on the command line.
+ Unless you build your application with the appropriate console setting,
+ you won't see the output. We can easily put \c console on the \c CONFIG
+ line so that on Windows the makefile will have this setting. However,
+ let's say that we only want to add the \c CONFIG line if we are running
+ on Windows \e and when \c debug is already on the \c CONFIG line.
+ This requires using two nested scopes; just create one scope, then create
+ the other inside it. Put the settings to be processed inside the last
+ scope, like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 121
+
+ Nested scopes can be joined together using colons, so the final
+ project file looks like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 122
+
+ That's it! You have now completed the tutorial for \c qmake, and are
+ ready to write project files for your development projects.
+*/
+
+/*!
+ \page qmake-common-projects.html
+ \title qmake Common Projects
+ \contentspage {qmake Manual}{Contents}
+ \previouspage qmake Tutorial
+ \nextpage Using qmake
+
+ This chapter describes how to set up \c qmake project files for three
+ common project types that are based on Qt. Although all kinds of
+ projects use many of the same variables, each of them use project-specific
+ variables to customize output files.
+
+ Platform-specific variables are not described here; we refer the reader to
+ the \l{Deploying Qt Applications} document for information on issues such as
+ \l{Deploying an Application on Mac OS X#Architecture Dependencies}{building
+ universal binaries for Mac OS X} and
+ \l{Deploying an Application on Windows#Visual Studio 2005 Onwards}
+ {handling Visual Studio manifest files}.
+
+ \tableofcontents
+
+ \target Application
+ \section1 Building an Application
+
+ \section2 The app Template
+
+ The \c app template tells \c qmake to generate a Makefile that will build
+ an application. With this template, the type of application can be specified
+ by adding one of the following options to the \c CONFIG variable definition:
+
+ \table
+ \header \o Option \o Description
+ \row \o windows \o The application is a Windows GUI application.
+ \row \o console \o \c app template only: the application is a Windows console
+ application.
+ \endtable
+
+ When using this template the following \c qmake system variables are recognized.
+ You should use these in your .pro file to specify information about your
+ application.
+
+ \list
+ \o HEADERS - A list of all the header files for the application.
+ \o SOURCES - A list of all the source files for the application.
+ \o FORMS - A list of all the UI files (created using \c{Qt Designer})
+ for the application.
+ \o LEXSOURCES - A list of all the lex source files for the application.
+ \o YACCSOURCES - A list of all the yacc source files for the application.
+ \o TARGET - Name of the executable for the application. This defaults
+ to the name of the project file. (The extension, if any, is added
+ automatically).
+ \o DESTDIR - The directory in which the target executable is placed.
+ \o DEFINES - A list of any additional pre-processor defines needed for the application.
+ \o INCLUDEPATH - A list of any additional include paths needed for the application.
+ \o DEPENDPATH - The dependency search path for the application.
+ \o VPATH - The search path to find supplied files.
+ \o DEF_FILE - Windows only: A .def file to be linked against for the application.
+ \o RC_FILE - Windows only: A resource file for the application.
+ \o RES_FILE - Windows only: A resource file to be linked against for the application.
+ \endlist
+
+ You only need to use the system variables that you have values for,
+ for instance, if you do not have any extra INCLUDEPATHs then you do not
+ need to specify any, \c qmake will add in the default ones needed.
+ For instance, an example project file might look like this:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 123
+
+ For items that are single valued, e.g. the template or the destination
+ directory, we use "="; but for multi-valued items we use "+=" to \e
+ add to the existing items of that type. Using "=" replaces the item's
+ value with the new value, for example if we wrote \c{DEFINES=QT_DLL},
+ all other definitions would be deleted.
+
+ \target Library
+ \section1 Building a Library
+
+ \section2 The lib Template
+
+ The \c lib template tells \c qmake to generate a Makefile that will
+ build a library. When using this template, in addition to the system variables
+ mentioned above for the \c app template the \c VERSION variable is
+ supported. You should use these in your .pro file to specify
+ information about the library.
+
+ When using the \c lib template, the following options can be added to the
+ \c CONFIG variable to determine the type of library that is built:
+
+ \table
+ \header \o Option \o Description
+ \row \o dll \o The library is a shared library (dll).
+ \row \o staticlib \o The library is a static library.
+ \row \o plugin \o The library is a plugin; this also enables the dll option.
+ \endtable
+
+ The following option can also be defined to provide additional information about
+ the library.
+
+ \list
+ \o VERSION - The version number of the target library, for example, 2.3.1.
+ \endlist
+
+ The target file name for the library is platform-dependent. For example, on
+ X11 and Mac OS X, the library name will be prefixed by \c lib; on Windows,
+ no prefix is added to the file name.
+
+ \target Plugin
+ \section1 Building a Plugin
+
+ Plugins are built using the \c lib template, as described in the previous
+ section. This tells \c qmake to generate a Makefile for the project that will
+ build a plugin in a suitable form for each platform, usually in the form of a
+ library. As with ordinary libraries, the \c VERSION variable is used to specify
+ information about the plugin.
+
+ \list
+ \o VERSION - The version number of the target library, for example, 2.3.1.
+ \endlist
+
+ \section2 Building a Qt Designer Plugin
+
+ \QD plugins are built using a specific set of configuration settings that
+ depend on the way Qt was configured for your system. For convenience, these
+ settings can be enabled by adding \c designer to the project's \c CONFIG
+ variable. For example:
+
+ \snippet examples/designer/worldtimeclockplugin/worldtimeclockplugin.pro 0
+
+ See the \l{Qt Designer Examples} for more examples of plugin-based projects.
+
+ \section1 Building and Installing in Debug and Release Modes
+
+ Sometimes, it is necessary to build a project in both debug and release
+ modes. Although the \c CONFIG variable can hold both \c debug and \c release
+ options, the \c debug option overrides the \c release option.
+
+ \section2 Building in Both Modes
+
+ To enable a project to be built in both modes, you must add the
+ \c debug_and_release option to your project's \c CONFIG definition:
+
+ \snippet doc/src/snippets/qmake/debug_and_release.pro 0
+ \snippet doc/src/snippets/qmake/debug_and_release.pro 1
+
+ The scope in the above snippet modifies the build target in each mode to
+ ensure that the resulting targets have different names. Providing different
+ names for targets ensures that one will not overwrite the other.
+
+ When \c qmake processes the project file, it will generate a Makefile rule
+ to allow the project to be built in both modes. This can be invoked in the
+ following way:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 124
+
+ The \c build_all option can be added to the \c CONFIG variable in the
+ project file to ensure that the project is built in both modes by default:
+
+ \snippet doc/src/snippets/qmake/debug_and_release.pro 2
+
+ This allows the Makefile to be processed using the default rule:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 125
+
+ \section2 Installing in Both Modes
+
+ The \c build_all option also ensures that both versions of the target
+ will be installed when the installation rule is invoked:
+
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 126
+
+ It is possible to customize the names of the build targets depending on
+ the target platform. For example, a library or plugin may be named using a
+ different convention on Windows to the one used on Unix platforms:
+
+ \omit
+ Note: This was originally used in the customwidgetplugin.pro file, but is
+ no longer needed there.
+ \endomit
+ \snippet doc/src/snippets/code/doc_src_qmake-manual.qdoc 127
+
+ The default behavior in the above snippet is to modify the name used for
+ the build target when building in debug mode. An \c else clause could be
+ added to the scope to do the same for release mode; left as it is, the
+ target name remains unmodified.
+*/
+