Since all gui applications already need some QPA plugin added,
we might as well add the default plugin and generate the code
to import the plugins automatically.
User can opt out from the automation by removing relevant
items from CONFIG variable: link_qpa_plugin or import_plugins.
Task-number: QTBUG-28131
Change-Id: Ic171c363464c099143374d3e39bcc28f6edf73d2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
generally, don't install anything from the top-level examples dirs
automatically. the global README and the aggregator examples.pro are
installed explicitly.
Change-Id: I5f6b8760f37d917b800fa85979896a471778cac0
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the feature was backported to qt 4.8, and people apparently started to
rely on it. it doesn't add too much overhead when not used, so enable it
by default again.
Change-Id: I15890027603ede733347f2c05b36ad1389c649cf
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
so other modules can actually re-use the code without referencing qtbase
sources.
Change-Id: Id66f07b476e539273dd32455e7642a17d7e5d0ef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Configure will now generate QT_DEFAULT_QPA_PLUGIN qmake variable
to specify the default QPA plugin.
"CONFIG += qpa_default_plugin" statement in application .pro file
will add the default QPA plugin into QTPLUGINS.
"CONFIG += qpa_minimal_plugin" statement in application .pro file
will add the minimal QPA plugin into QTPLUGINS.
Task-number: QTBUG-28131
Change-Id: I12a241005f30b37467d783b50f0369b47e605e68
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Platform plugin is needed always when gui is linked to an application.
This is tedious to do manually for static builds, so provide support
for generating a source file that imports static plugins for
application projects.
"CONFIG += import_plugins" statement in application .pro file will
generate required import statements for all plugins specified with
QTPLUGIN variable.
The plugin class names are found from plugin's module pri generated
automatically when plugin is built, as long as the plugin specifies
the PLUGIN_CLASS_NAME in the plugin .pro file before loading
qt_plugin.prf.
Task-number: QTBUG-28131
Change-Id: I19f8ea48a3c1e9b5c81f4399c4b5d439a6d4bea1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Usage of QTPLUGIN implies static Qt, so only handle it when that is
true so user projects do not need to scope it if they support linking
against both static and shared Qt.
Change-Id: I011b4672bac122d7d64d8f2fc0e41ca7e5251dfc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Since QTPLUGIN variable values are used to locate both the plugin
library and the module pri file, those must match. Therefore generate
module pri file name using the TARGET of the plugin rather than the
pro file name.
Change-Id: I9ec6f2a087ba3b3cecf7034c8a28b31df155cd97
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
there will be more template data, and it wouldn't be too nice
to spread it all over mkspecs/.
Change-Id: I909c48d26ac34f8c0f66051a65d326366d49c096
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
this should have been in 048b697c07.
Change-Id: I8589453ef937db1a9a446b0e5d01bb830b0cf6b0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This follows the same logic used to set bsymbolic_functions.
Change-Id: I9300eab8a1b6673c4409b5dd07b40123fdf00d69
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The contents of this eventually go into a CMake target
property IMPORTED_LINK_INTERFACE_LIBRARIES, which seems to expect
sorted input. Usually the contents is generated by CMake itself,
so generating content it expects is reasonable.
This fixes the qtactiveqt cmake unit test with MingW on linux.
Change-Id: I2a540bea5c3ac214ad4e1dfedfb7cbd2f863472b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
now we may get files with several mentions of the same lib/include dirs
on the same line, but that's essentially a non-issue.
Task-number: QTBUG-28336
Change-Id: I8204086420b82015f62090ae0a56908ce0cccee8
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this seems more generic, and allows for more substitutions inside the
generated files.
Change-Id: I7a2e37036f9f9f7dbf7f28f0976ef427dd28ee82
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the "export location" of the linguist tools was just bogus, and lconvert
was missing anyway. the two dbus tools and qdoc were missing, too.
generally, it seems useless to report the paths of some random tools -
instead, just report the install location of the host binaries and let
users figure out the complete paths themselves - this should be ok, as
we decided that distributors are not supposed to do tool renaming any
more.
for the binary path just use the final location, as the files won't be
used before installation anyway. this allows us removing the scary
generic prefix replace from the pc file installs.
and as a side effect this also fixes debug_and_release builds of core
and widgets by not loading various prf files prematurely and thereby
messing up the dir replacement magic.
Task-number: QTBUG-28286
Change-Id: I99de419301fc07fb923959db4bd5cab9072d1c31
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
in particular for the meta Makefiles of debug_and_release.
the logic is as follows:
- the meta targets ('html_docs' in prepare_docs mode, and 'docs' always)
need to branch out asap, so they are implemented non-recursively in
every makefile.
- all other targets need to be fully recursive. the meta Makefile will
recurse only into one of debug or release, depending on the configure
option (it doesn't matter anyway).
Change-Id: I4e3f714cdda9c3a1021743148b5ee73379e3484d
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
there is no reason why something should break out of the system.
Change-Id: I081bffc0927b43ac4940d0200e32e1e60f6f2e97
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
complementary to QMAKE_RPATHDIR. this avoids that we need to sprinkle
linux/gcc specific code all over the place.
Task-number: QTBUG-27427
Change-Id: Iebafd1749d1a0d803704902473df8c743f074ddc
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
all modules have been migrated to auto-generation
Change-Id: Ie7b3ebfd735a22f8e0b0339909b6385508d7a6b3
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
turns out that some modules need a lot of work, so make it opt-in for
the time being.
Change-Id: I16365e3d96adab98a1bc748907dbd67488dfad5f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
instead of letting *every* qmake-based project have recursive check target,
let interested projects "subscribe" to it by adding CONFIG+=testcase_targets
in a central place (.qmake.conf, which Qt itself does via qt_build_config.prf).
Change-Id: Ib13fdd2d3a1adee0c5ad02b6b176a664c583bf9d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Add a 'd' to debug builds to allow both release and debug builds
to be used.
- Add .def-files for Debug
- Build all libraries debug/release
- Add description to README.qt
- Differentiate debug/release in qmake.conf.
Task-number: QTBUG-28196
Change-Id: Ib3081004a6ed2ad71d353244154684d2e0ebbc86
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
QAxServer projects must not link qtmain.lib.
This awful hack was adapted from the old qaxserver.prf
Change-Id: I78b4cbf6714bfbd88341449b9230f1989cff8a6f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
we directly expand $$TARGET on the same line, so just do the same with
$$VERSION
Change-Id: I3601bfcc835b13f63dce43d00cfe8d34ded60b21
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
we are assigning QT.*.VERSION from VERSION a moment earlier
Change-Id: Ie4d51f8835b8050755bc399a1a597967c8e3e499
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
it's confusing for the users if the examples' project files contain code
to install their own sources. also, this constitutes an enormous code
duplication, and lots of mistakes. consequently, automate it.
more or less as a side effect, this also removes the entirely meaningless
target installs in subdirs projects.
Task-number: QTBUG-28184
Change-Id: I9fc1367a06db9e2c46aeb67d68729a4f67163ef9
Reviewed-by: hjk <qthjk@ovi.com>
instead of letting *every* qmake-based project have recursive docs targets,
let qt modules "subscribe" to it explicitly by having load(qt_build_config)
in their .qmake.conf (which they already do).
Change-Id: I97b74591fd0c4bd5f8b08c5f550df9c7eef2f556
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
User applications are those that users run directly, whether it be for
development or not. The executable binaries that the user does not
usually run but is still required for proper functioning are called
"program executables" in Autoconf and they are placed in libexec.
This commit adds support for "program executables" in Qt by adding the
-libexecdir option to the configures, the qmake variable
QT_INSTALL_LIBEXECS (note the plural, to match all other properties),
and QLibraryInfo::LibraryExecutables.
At the time of this commit, the only expected "program executable" is
the QtWebProcess, the WebKit2 helper process from QtWebKit.
Change-Id: I66c3a3e0cf7f9d93b5f88f55f18e957faff608fc
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
- the old docs target becomes html_docs
- a new qch_docs target is added. the .qch files end up directly in
QT_INSTALL_DOCS, wihout any subdirectories in between
- the new docs target invokes html_docs and qch_docs
- respective un-/install targets are added as well. note that the
install targets don't depend on the build targets, as it's virtually
impossible to get the dependencies right throughout the hierarchy.
Change-Id: I07a2589db8252371e77cf925c47c4e59fbd1b2ca
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
