this function is called only from library TEMPLATEs, and always with
exactly one word as the only argument.
Change-Id: I6282e3826791f89e6cf89dde625c8166e4e56028
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
these have no (useful) install target, so it makes no sense to reduce
the "build" to installing sources. suppressing the actual build can be
achieved with -nomake examples instead.
conversely, as the build dir is the install dir, people actually need to
be able to (selectively) build examples in there.
Task-number: QTBUG-29756
Change-Id: I98f34235442b552e51c0d5f5cec96a3eab4f1e7f
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Instead of setting -isysroot in both arch.test, compile.test, the various
mkspecs, and sdk.prf, we now propgate the chosen SDK as the qmake
variable QMAKE_MAC_SDK, which is then handled exclusivly in sdk.prf.
The QMAKE_MAC_SDK variable, and -sdk argument to configure, is expected
to be of the short-form name, eg macosx or iphoneos, not a full path, as
that's what Xcode also expects. We take care of translating that into
a full path for -isysroot/-syslibroot in sdk.prf, using xcodebuild as
a helper.
Change-Id: I281655b2fa5180c6e78ffdce36824e4a91447570
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
... instead of as a fallback in default_post.
it was this way in qt4, and it requires less code to be written in the
end. we are already doing it for debug/release as well.
Change-Id: I6e02849d61d14a18375cf64a5990768931ebac48
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
all tests that happen after default_post loads resolve_config can rely
on debug vs. release, static vs. shared, and staticlib vs. dll being
properly "de-conflicted".
Change-Id: Ie0b4defcd6024bd1c25f53ba7e03621052d96492
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the current approach of having "free-flying" prf files for such a core
issue is rather insane. this was noticed early on, as evidenced by the
forcible loading of debug/release/debug_and_release in default_post.
however, things remained a mess, in particular static vs. shared.
consequently, the commit merges all related feature files. the actual
config resolution is put in a separate feature file, so it can be loaded
by resolve_target if that happens to be loaded early on.
Change-Id: Ie30e7c63cabe9409a3263ca1650e323a870926f2
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it differed from QMAKE_LIBS_OPENGL only for the irix/sco/unixware -cc
specs for not entirely obvious reasons. as all these specs are obsolete,
remove it.
Change-Id: I7d50ffa11ff830371ea52c9ebe25e1f1bc56b307
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
there is mightily little point in unsetting variables right before
unconditionally assigning to them.
Change-Id: I24c1814ce38bf9aab4496679b1a670f3cd55c536
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
If Qt is configured with -libdir /some/dir/outside/the/install/prefix/,
then for use absolute paths for the executables and include dirs too.
Change-Id: I5ccf62be6f93f97d934df62038fe4cd40dca9a93
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
all non-installed tools are properly registered, so they don't need the
fallback. conversely, we can assume that non-registered tools are
already installed.
this enables us to build docs in qtbase after an incremental
build+install up to qttools.
Change-Id: I95a55f6b84e01885bcf6dd656caf0dd2b679bb73
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This is the <prefix>/include directory which is independent of the
module and which only has to be used once. As everything uses QtCore,
it is enough to set it only there.
The CI system is a special case, in that it tests things before
installation. Handle that case too.
Change-Id: Idcdf9617e199b7d490cb3553cce07f1f464b3bec
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
As the Extras file can do things like append to a property (as in
QtCore for include directories), that is something that should be
done only once when the QtCore target is first defined.
Change-Id: I5163912bccfda1ff43a02eb01f67ac59e6f6b24b
Reviewed-by: Alexander Neundorf <neundorf@kde.org>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
the pkg-config file names follow the TARGET by default. as we create
frameworks without the major version infix, all references to Qt5* would
be invalid.
Task-number: QTBUG-29453
Change-Id: I82e7de017a8f17f7d2d7b4a2a61a180125ca29a0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it's not used for anything other than display, so we can put a space
there.
Change-Id: I77e156856efeaaa964ff3bf2369bcd5586bac7c6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
there is no point in duplicating the information in every module.
host_bins is exported only here as well.
Change-Id: I2f816e1cade9761a2c0d97c7ca1c90293095bfb1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
users need access to the Qt configuration, not some internals of
module's build system.
Change-Id: Ife3f668282969d444282d57152c11ed0f741076f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
-rpath does *not* imply -rpath-link when x-building:
ld(1): "Searching -rpath in this way is only supported by native linkers
and cross linkers which have been configured with the --with-sysroot
option."
it doesn't hurt to have the "excess" -rpath-link for native builds, so
just remove the cleanup.
Change-Id: Ic39c1f4d6c2e3770d43a5ed3e56cf89a146edf85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
if the libraries are in a non-standard location, but no rpath is used,
rpath-link is needed. this is often the case for non-prefix builds
(which have no forwarding pris any more).
as we cannot store absolute paths in the final pris, we need to store the
module names, and resolve them only at use time.
Change-Id: I1538b5d531611c76a2d7058a3b2ff683bdcbe427
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
as everything is built inside the common build/install dir, there is
no point in the fwd pri stuff.
as a "side effect", this makes it more straight-forward to relocate
non-prefix builds, which is the default on windows.
Task-number: QTBUG-28827
Change-Id: I010246a9ad87cf74974dc168768b1a8625f73260
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
move the regular pri file creation into the "sub-prf" and rename it
accordingly. the original reason for the split was the deep magic in
activeqt (and phonon), which is gone now.
Change-Id: If40e941afc9293725630ed6bcf3e4ef18a692f66
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
-developer-build enables an actual build of examples, based on the
assumption that developers want to test it (it can be still disabled
with -nomake examples). regular users otoh want only the examples
sources installed.
Change-Id: Ifc6a108099929175a3960480802b271a758fdd38
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we need to collect the sources of the install targets for the check that
all files have been properly handled, but of course we must not add these
files to the source install target, as that would mean double installation.
Change-Id: I6acb56f2a993b6ed81d1031d5dc0a0da30a53b54
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Curiously, qmake could fix .prl and .pc files for unix, but only .pc
files for MinGW. qt_module.prf seems to have known this.
Task-number: QTBUG-28902
Change-Id: Ice9983a69813690c0d4b96ca11589440182569a0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Fully modular prefix build now puts the includes and libs into each
module's own builddir, so the else branch was simply bogus. Replaced
the else branch with the real base for modular builds. This allows
the paths to be successfully replaced when installing metafiles.
Change-Id: I056a923288965b560a4e9b0ba7add1aac912199f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
otherwise qmake will just take TARGET and lowercase and capitalize it,
which not only looks weird, but also does not match the Requires: fields
we generate.
Change-Id: I4a070ff256fffd2b780acb0361d4213d0032dbb9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Dihan Wickremasuriya <nayomal@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
This is a less error-prone way to calculate relative paths.
Task-number: QTBUG-29110
Change-Id: If4509ef278e48dcf08bdcc904d21534b4c05993f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Cross bulding on unix for mingw exploits the fact that makefiles
generated for mingw work with plain make. There is no mingw32-make, so
this is the only option.
Arguably, plain make could also be used in an MSYS environment,
perhaps detected by MINGW_IN_SHELL, but there might be good reasons I
don't know about not to do this.
Change-Id: I694c74046a307c2887af1c30cca36f95e242adc1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
this is much more elegant than the so far propagated !isEmpty(QT.foo.name).
also replace feature-specific tests (no-gui and no-widgets) and the
obsolete contains(QT_CONFIG, foo) syntax.
Change-Id: Ia4b3c8febcabf9eeca67b1f9173a523820b1038b
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Tasuku Suzuki <stasuku@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Fix MinGW build errors by using the standard main signature.
Change-Id: I0ebe7307a825a7ec50e654f163fbf8fe7060a478
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Generalize the check for gui by checking for needs_qpa_plugin
CONFIG value instead, which gui adds to MODULE_CONFIG.
Task-number: QTBUG-28215
Change-Id: I5834a3f81e5c3868ee1a3fa405ebc6410db1f900
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Using some modules requires importing static plugins also for shared
libraries (namely QtAxServer), so provided a way to force plugin
imports even for non-applications using force_import_plugins
MODULE_CONFIG value. This required moving the plugin handling after
qtAddModules calls in qt.prf.
Task-number: QTBUG-28215
Change-Id: Id6bb92ed7c078cc8c54538ddc9bb8e8ad316f277
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The location of the mkspecs directory comes from the archdatadir, which
distros will all set.
Change-Id: I20dbdce76db13dbd37eec065009e215f98985907
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qt is already added by spec_pre.prf, warn_on and depend_includepath by
default_pre.prf.
Change-Id: Ic00e0ba496d698ed9659c476f2ca99fc0f86a093
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
When building Qt static, plugins get module .pri file, but those files
do not get installed in Windows. This is because both .pri generation
and install target statements are scoped with !build_pass, which means
Makefile.Debug and Makefile.Release do not get install_pritarget
target.
Fixed by doing only the .pri generation in !build_pass scope.
Task-number: QTBUG-28606
Change-Id: If3f49b578af1d9171a8bce67793ecb3f902a6da8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
it's the very antithesis of modularization to do it.
Task-number: QTBUG-27722
Change-Id: I2540e1a70e67b55420246d0c209314c05c65a85f
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
The variables these files refer to are not set anywhere anymore.
The Unix thread.prf file is still needed, as it is still effective and
is activated by qt.prf.
Task-number: QTBUG-25106
Change-Id: Ia514192d28785205df3710d78ee597285d4136b0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
rpath is meaningless for static libraries.
and windows has no concept of rpaths to start with.
Change-Id: Ia02bbdfbf7112e7082175c3051c0839ac0900f57
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
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>
On QNX e.g. you'll end up with a Qt configured without pkg-config support
by default. Once you try to compile e.g. QtWebKit which contains a check
like packagesExist(libudev) the system pkg-config (see default branch
of pkgConfigExecutable) will be called without any special config sysroot
or libdir. Thus libudev will be found in your system host, even though
it is not available for the cross compile target. This leads to compile
errors as described in https://bugs.webkit.org/show_bug.cgi?id=98032 .
Change-Id: If1474cb3b3f3b71fad7269e4aedd4e10f70a9b2a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Added prepare_docs to qt_build_config.prf (it was added
directly in configure in the source branch)
Conflicts:
configure
tools/configure/configureapp.cpp
Change-Id: I1337c69fc62b1c934e3e39b4409e4857440c9db8
This commits adds a -qmldir configuration option for the configures to
allow the user to change the default location (it defaults to
$archdatadir/qml).
It adds a QLibraryInfo::Qml2ImportsPath value for
QLibraryInfo::location, a qmake property of QT_INSTALL_QML and a qt.conf
configure location entry "Qml2Imports".
At the same time, it makes the qmake .prf files dealing with QML plugins
be the QML 2 version. Those files are new in Qt 5, so we have the option
to choose which version we want to use.
Discussed-on: http://lists.qt-project.org/pipermail/development/2012-October/007136.html
Change-Id: I8c1c53e8685a5934ed0a9a42ba5663297b81a677
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
as a "side effect", this fixes the build of bootstrapped tools when
doing a debug build under msvc: qt.prf would add CONFIG+=release after
default_post.prf already loaded debug.prf.
Change-Id: Idd17cf28d358950fd90bb18ca7a8d67e06953bc1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@digia.com>
This ensures that for example the platform plugins get properly
re-linked when the static platform-support lib changes.
Change-Id: Iad493d4de30d6f6977f80aa56d0b27d05e9e3770
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Change-Id: I3b277316b1befbb57613b465fc5bbedc6b2305f7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
the fallback path wouldn't account for a sysroot. as there is no clean
way to implement that, rather remove the fallback alltogether and make
the rpath a mandatory part of modules.
Change-Id: I6f2bd6e36889be2f61e17a579174380aa3c6622d
Reviewed-by: Romain Pokrzywka <romain.pokrzywka@gmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Making a properly installed libQtBootstrap simplifies
our tools build process a little and in addition allows
other comand line tools to use the bootstrap lib and
link against it.
Initial-version-by: Lars Knoll
Change-Id: Iddf4568a5505bc24898ec1abf7e7022e19f0a454
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the respective flags/defines need to be prefixed with a minus sign.
Change-Id: I8a3a46254f90d4ecdbd692a0eca635038691d078
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this makes it possible to configure with -nomake tests, but have, e.g.,
QTSVG_BUILD_PARTS="libs tools examples tests" to enable tests
specifically in the svg module.
Change-Id: I925ab955ac32ec3e311c2a852a51b098fd4e0ea3
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Janne Anttila <janne.anttila@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
qmake automatically appends the library's major version number to the
DLL file name on Windows, as DLL naming doesn't include the version
number on a suffix like on Unix systems.
This flag makes it so qmake skips adding. This will allow us to insert
Qt's major version number at a different position.
Change-Id: I25d471038841fb0c5a34ef6b3bd6266aa33cebd1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
otherwise we may remove a user-provided setting.
Change-Id: If3217a3d92938fe2f3ac3740a645d3ace0ce9ab0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it's basically an attribute of qtcore (and everything that depends on it).
Change-Id: I6eeefeb5df70764399d9f22dca9dbec1843b8d68
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we now have qt_build_config.prf which can contain static code.
Change-Id: I3f0ae142fdc5ffb4e1d25e628e809ba15b5f0ac4
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the function is automatically performed by debug_and_release.prf,
regardless what we do with this flag.
Change-Id: Iddec69b35e0e905fdf4133ee240af37d3a8ada0b
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... and use them in qt.prf instead of (not) maintaining hand-coded lists.
Change-Id: Ia21f7864eaf3ca92fa75f23876f71075d0521f4b
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
this is less expensive, as qmake already provides us with it.
Change-Id: Ifb44ea9126e6b52c02025858c5d88032e7a6cc2a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it now defines the DESTDIR and creates an INSTALLS rule.
Change-Id: I15a462ccad9acbe3521c352fa98327825dc27c05
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
these are in fact thin wrappers around the qml2 variants, which got
respective hooks.
Change-Id: I1190856aea3f454b6f163e147d39c707a35ec4c6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
set DYLD_FRAMEWORK_PATH instead of DYLD_LIBRARY_PATH
Change-Id: I9849f12063b8c7a45d040c087f4611c3a48180b8
Reviewed-by: Johanna Äijälä <johanna.aijala@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
while plugins for libraries need to follow the -debug-and-release switch,
plugins for tools must follow the single-config approach of tools.
Change-Id: I8a79e98034d2ff8b5d4e6191a9143c9472a5aa02
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
we now have tool and soon plugin pri files. make them easily
distinguishable.
Change-Id: I8904e4182227a78060121e8712446bc43b1dd185
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
use $$MODULE_BASE_OUTDIR & $$MODULE_QMAKE_OUTDIR directly.
this is a no-op, except that now module pris will be built in qtbase for
all modules when building without -prefix - which is only consistent with
all other artifacts.
Change-Id: I2965b2c7a15aa9e82ba6017f5f4c0daa14b6e6fe
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
it is a bad idea to extract plugin paths from library modules.
instead, just collect plugin paths from all known repositories.
Change-Id: I527325f20e9cf98ae974997530af1b2893537e5d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
qt_debug & qt_release are dead, so collapse the respective paths and use
an existing function.
Change-Id: Ie800be477186a6eab72682d367b24e83c3b9bbc0
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
this is qt module specific magic that has no business in the generic
default_pre.prf.
a side effect is that every qt module now needs to have a .qmake.conf
(unless it sets MODULE_QMAKE_OUTDIR, like webkit does).
Change-Id: Id9e5f6eee2d8ec0c711e7217d9e1893fc9c88132
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
should now actually work for all build types
Change-Id: I2dc1f8231737c13e95ce8aab1330b4f063951547
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
