Depending on the presence and behavior of HEADER_MODULE/header_module
in CMake and qmake land, the module.pri might end up with an empty
module line, which means adding the module via QT_PRIVATE += entrypoint
will not link to the static library.
To avoid this problem we write an explicit module entry (QT.foo.bar)
into the same module.pri file as the one generated by qt_module,
where the auto-generated one has header_module enabled, and hence
no link behavior, while the manually written entry has a module
component, and will ensure linkage to the static library.
Change-Id: Ib98484f74410fab45c4d109f3610028200fba0c5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The flags go before the library in the final linker line, as opposed
to the dependencies declared in LIBS.
This allows us to declare the flags for the entrypoint
in the project file of the entrypoint, instead of in
a standalone prf.
Change-Id: I35c054fe9fdaa6add7cd0e8ba3f7304f975ff80f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On the qmake-side we had exports, but they were quoted.
Change-Id: I95af4b927079691cab6403fec850f345ba181a00
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Multi arch build in one go is need to support the new .aab packaging format.
By default the users apps are built for all Android ABIs: arm64-v8a armeabi-v7a x86_64 x86
The user can pass ANDROID_ABIS to qmake to filter the ABIs during development,
e.g. qmake ANDROID_ABIS="arm64-v8a armeabi-v7a" will build only for arm ABIs.
[ChangeLog][Android] Android multi arch build in one go,
needed to support the new .aab packaging format.
Change-Id: I3a64caf9621c2a195863976a62a57cdf47e6e3b5
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Do not store this variable locally, because
a) it might change if the SDK location changes
b) does not play well with Qt installer packages which would provide the
include path of the build machine.
To achieve this we introduce the (usual) magic value - for
QMAKE_EXPORT_INCDIR_VULKAN to denote "do not export this value".
Fixes: QTBUG-73796
Change-Id: Ied26ee12cbcdf7f5f6e1caef5d29dadf6309c5d6
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
we already knew the dependencies (as they are declared in the json
files), but failed to export them in any way, which made linking against
statically built external deps which have deps in turn fail (unless the
project happened to pull in the dep anyway, as is the case with qtcore +
zlib).
the previous assumption was that the USE-able library objects would be
self-contained, but that is conceptually unclean. instead, properly
export the raw dependencies and resolve them only in qmake_use.prf.
note that pkg-config produces self-contained output, so we need to
actively subtract the dependencies we know.
Change-Id: I4b41a7efc05bbd309a6d66275d7557a80efd5af4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the borrowing of headers always happens from "proper" modules which are
actually built as frameworks if so requested. that means that even
though the borrowing module itself never is a framework, it needs a
framework path and include paths that point into frameworks.
amends 20c7ab44.
Change-Id: Ic582060dd179cc592e9be7792ff02cebdfabd772
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
a header-only library in a default location would produce no variables
at all, making it appear undefined. fix this by forcing the writeout of
the QMAKE_LIBS_* variable, and use its definedness (rather than
non-emptiness) as a signifier.
this works for both QMAKE_USE and configure tests'/libraries' 'use'
entries.
Change-Id: Id7a1e23725caba1a91ea4db448b4aeb7fe632393
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
these are not referenced anywhere, and neither should they, as they are
not relevant to _using_ these modules in any way.
notably, QT.*.bins remains exported - this is because dlls reside there,
so it is necessary for setting up a launch environment.
Change-Id: I7a33c72be6e4789ea29a2fbbcac9588213900b6e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the only users of module versions in the first place are found within
qt's own prfs; even qbs' qt module importer ignores them. but arguably,
the information makes sense.
however, exporting the same barely useful information redundantly is
plain over the top, so remove the pre-split representation.
Change-Id: Iaee69c86d8b7c8b8ef4f3580b8da333aeb8ade2c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
all users of this functionality have been removed, and not emitting the
version info saves quite some noise from the generated files.
the reason why the users have been removed is that it was unreliable in
the first place: if a dependency is found without pkg-config, no version
information would be available.
the extraction of the version via pkg-config itself is kept in place, as
configure tests could be potentially optimized by utilizing it.
this reverts much of commit 48b4e0bf6f.
Change-Id: I01917f3b2a56b747d7cc54955141d20d23d0990a
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this code is meant to strip off the file name if provided (as the
accessibility plugin in qtdeclarative does), but clearly overshot the
mark by stripping the subtypes (as needed by qtmultimedia, and soon
qtbase as well). use a stricter regexp which matches only names with an
extension, which is a Good Enough (TM) approximation.
Change-Id: I63afe9c7b1b0ebf4da530dcf558e9c84ae3c85ec
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
when a module makes an external dependency part of its api, the users of
that module need to know the include paths (and possibly defines) of
that dependency, and also need to link to it explicitly if they want to
access symbols from it directly.
this patch implements this via the usual qt module pri mechanism.
limitation: the external library definitions are in the private pris,
so technically a public module is not allowed to make its external
dependencies public. we don't have (and don't anticipate) such a case.
Change-Id: I2dbbdcfcfc1b200acae151a969976cd668e24f89
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
with the new configure system, all modules which have a configure.json
also produce a private config header. the forwarding module pri needs to
reflect that.
Change-Id: If79e10a2643d55ad9aa9815f20297d36d9b9feec
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This change implements the required infrastructure to modularize the new
configuration system.
This requires a hierarchy of configuration files, both for handling
multiple repositories and for individual modules inside the same
repository.
When configuring, they all need to get loaded first, as command line
processing needs to know about all possible command line options.
When the command line has been processed, the individual configuration
files need to get processed one after the other and independently from
each other.
Configure is now automatically invoked when building the a project
tree's "root" project; this works with both modular and top-level builds
of Qt (the latter with an according change in the super repo). As an
immediate consequence, the -skip option moves to the super repo with a
different implementation, as configuration is now done after the repo
list is determined. The option belongs there anyway.
This commit also adds an optional testDir entry to the json file. Like
this, we can still have all configure tests in qtbase/config.tests and
the configuration file in, e.g., corelib can reference those.
The files section can now be left out as long as a 'module' entry is
present, specifying the module name. The names of the files to generate
can then be deduced from that name. We still need to be able to specify
names directly for the global configuration files.
qtConfig() now also queries features which are module-specific. As it is
sometimes necessary to query the configuration of modules which should
not be actually linked (and cannot in the case of subdirs projects), the
new variable QT_FOR_CONFIG which allows specifying configuration-only
dependencies is introduced.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: Id1b518a3aa34044748b87fb8fac14d79653f6b18
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
get rid of the entirely superfluous stock "Aborting." messages -
the event triggering the exit has already reported the problem.
Change-Id: Ib9dfb9e4212f60eceb2ea432cdf56c5a8afe9d65
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
So far no capabilities (but internetClient for Windows 10) were added by
default, which forced developers to always manually edit the
WINRT_MANIFEST.capabilities(_device) property.
This allowed to leave out non-required capabilities and keep the created
manifest clean, examples being microphone for multimedia.
However, this also breaks first user experience as deeper knowledge
about this topic is required. Furthermore this is inconsistent with
other platforms like Android, where all capabilities are set by default
and developers need to edit the manifest manually in any case.
With this change, modules can define the capability set to enable all
features in the module. If developers want to disable some again, they
need to adapt the generated manifest. From our experience this needs to
be done in any case, latest at publishing stage when the store
manipulates the manifest.
Task-number: QTBUG-38802
Change-Id: I6d522268ee0afbfa00a30dbdd5e6ec9f415bebf3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this is necessary for:
- generating -rpath-link arguments when link_prl is not used. link_prl
is enabled by default, so this has no effect on most projects.
- deployment purposes, which is hypothetical as of now.
Change-Id: I9e629f3eef93c4edf12efc016ecc27dbe2186d61
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
turns out we need forwarding .pris in this case: without them,
QT_MODULE_INCLUDE_BASE points into the build dir, so we fail to find the
pre-generated headers.
an alternative would be writing primary module .pris which already take
that into account, but that would just add even more arcane code paths.
Task-number: QTBUG-51521
Change-Id: I59f2a0d3f2095c9dfa0a8d1cabfc007a30bd2d23
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
most module project files define two logical modules: a public one and
the corresponding private one. these are really separate modules as far
as qmake is concerned (even though the private one contains just
headers), and consequently have separate dependencies - QT and
QT_FOR_PRIVATE.
as public modules cannot depend on private ones, all private
dependencies would have to go to QT_FOR_PRIVATE, and a dependency on the
respective public module would have to be added to QT. this would be a
bit tedious, so we have a convenience feature which allows putting
private dependencies into QT, but automatically "downgrades" them to
their public counterpart when creating the public module's .pri file.
however, we failed to put verbatim versions of these private
dependencies into the private modules, which meant that these
dependencies were not pulled in transitively by the private modules'
users.
note that this entirely unrelated to QT_PRIVATE - this one defines the
private (non-propagated) dependencies of the module's implementation,
i.e., the libraries (and headers) that are not part of the link
interface. there is no QT_PRIVATE_FOR_PRIVATE, because there is
obviously no point in assigning the dependencies to a particular
logical submodule when neither one inherits them as far as the qt
module system is concerned.
Change-Id: Ib056b47dde3341ef9a52ffff13efaf8ef8e6817b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
save the actual library/framework name and framework paths in the .pri
file instead of computing them again at use time in qt.prf.
qt_no_framework_direct_includes inherently requires a use-time decision,
so this ugliness remains.
Change-Id: I09b2775e7d8e1d52e3af0d663e1babde10ae4814
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the main objective was to fix the bootstrap modules in framework builds.
bootstrapped modules which "borrow" headers from "proper" modules can
specify this in a clean way now.
a side effect of this is that the bootstrap-dbus module now has its own
syncqt call.
most includepath-related setup from qt_module_pris.prf was moved to
qt_module_headers.prf.
Change-Id: Ie0d8192cfac1a8cdae0ddd0bc0cd8c3092b1e85b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
CONFIG+=qt_framework is actually put into qconfig.pri, so it's always
set in framework builds. things (sometimes) worked only by virtue of the
qt_framework checks being in "else" branches of "static" checks. use
lib_bundle instead, which triggers the actual framework build anyway.
amends b72d1db44.
Change-Id: Ib725c43476d9fb38bad940ce09905d29ff3edfa3
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
the rpath applies only to the installed on-device location and is
consequently always the same for all modules, so there is no point in
indirections.
Change-Id: Ia0590552aa317d799a2d3879fd0c0768344b9645
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
while every "real" module has private headers, a very small headers-only
module could reasonably have none. entirely hypothetically, of course. ;)
Change-Id: Ib51a66858fb7d62f45fe2928625c25aa1ffc2827
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
they have no library to link against, obviously.
Change-Id: I721670382c1ec56e19130f0a0ecef616e101b885
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
spaces in the source dir are not supported for now, as that requires
some more profound refactoring of the bootstrap makefiles.
Change-Id: Ie0c07a1558b8326f642f2ea144bc1cd85ee761af
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
these reflect the on-target paths (unlike /raw, which are host paths, just
without the -sysroot). this is necessary for anything deployment-related,
starting with RPATH.
Change-Id: I13d598995d0e4d6cb0dc1fc7938b8631cf3e3a95
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Whenever a binary is created and linked against a static lib that was
compiled with LTCG, the final linking step requires the compiler flags
so that the pre-compiled data in the shared library can get properly
compiled.
This could happen for a static build of Qt with LTCG, but also happens
frequently for Qt's own build when linking regular libraries and
applications against QtBootstrap or QtPlatformSupport. The linking fails
when the target is a shared library (example: QtWaylandClient linking
against QtPlatformSupport).
The .prl file actually contains the "ltcg" flag, so the best solution
would actually be to process that flag there and add link_ltcg if any
dependent .prl has "ltcg", but I couldn't find out how to do that.
Change-Id: I4a75a14d1dcb8c2089a427285e25d5555df7d7d3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
when a module delegates to another module (as the activeqt ones do), it
doesn't have a master header to be included. we could derive the real
master header by doing a transitive dependency resolution and some
filtering, but that seems unnecessarily complex.
Task-number: QTBUG-41892
Change-Id: Ie7ce51a837ac06e929b204ec734206c11b3ae241
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
when doing a module-by-module build, we need to also use includes and
libraries from the install tree, as it contains the current module's
dependencies. but a pre-existing installation of the current module must
not be found first, as it would cause trouble latest when it was somehow
incompatible.
but purely topological sorting of the dependencies could cause the
locations to be mixed up. therefore we give modules which are part of
the current build a priority boost.
Change-Id: I8fdbb46f0a2a630781c8a2177468039c1122151a
Reviewed-by: Giulio Camuffo <giulio.camuffo@jollamobile.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the plugins already declare which modules they belong to.
additionally, we allow plugins to declare which modules they "extend" -
e.g., while the Quick accessibility plugin belongs to Gui's 'accessiblity'
type, it makes no sense to link it unless Quick is actually linked.
finally, it is possible to manually override the plugins which are linked
for a particular type, by setting QTPLUGIN.<type> (to '-' if no plugins
of this type should be linked at all).
Task-number: QTBUG-35195
Change-Id: I8273d167a046eb3f3c1c584dc6e3798212a2fa31
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the module project files declare what plugins they need, as that is
necessary for automatic android deployment.
enable wider usage of this by making the information available from the
module .pri files.
caveat: the variable is called "types", but is in fact paths, so there
can be particular plugins named.
use this new facility to replace the egregious hard-coded list of
plugin-to-module mappings from create_cmake.
possible todo: automate populating DEPLOYMENT (for wince, and whatever
else).
Change-Id: Ibb9c07cfe2b0008905204cbeb81e9c8e2ae4dc69
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
instead of being magic attributes of the main modules, the privates
are now proper modules of their own.
this cleans up some code paths, is more mappable to other build tools,
and enables private modules to depend on other private modules.
note that the library path is needed even in the "empty" private
modules, as in the framework case that's where headers are found.
consequently, the modules need to be explicitly marked with the new
"no_link" flag. this required some reorganization of qtAddModule().
Change-Id: I8e4f44a609f8d639cc01bcb658256870a627eb63
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
the previous attempt broke ActiveQt, as it actually has public modules
without headers (they are provided by a common base module).
so explicitly mark the internal modules as such instead of applying
heuristics.
Change-Id: I8d8a2ee66f02c3444da2036a497e7f382f089f62
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
make the include dir in the source tree the "main" include path, as
that's where the majority of the headers is. then selectively add the
shadowed dirs.
Change-Id: I03ad13cfcf77175c141b94d41b1221740d851faf
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
all private headers are created by syncqt (and are thus in the source
dir), so we can simply override the normal (build dir based) paths
instead of extending them.
Change-Id: I9c1f3344c401b481b3f3d2295515f1aabffaa9a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
