Initial support for INTEGRITY to build QtBase
Change-Id: I18f36b4dea9107f01e1c281e4b62880590c777a1
Reviewed-by: Tuukka Turunen <tuukka.turunen@theqtcompany.com>
Reviewed-by: Nikola Velinov <nvelinov@ghs.com>
Reviewed-by: Risto Avila <risto.avila@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the second dash would end up in the option name, which made it obviously
unrecognizable.
but the second dash isn't optional in the first place (as evidenced one
line up), so remove the question marks.
Task-number: QTBUG-57908
Change-Id: I6622fef7d11d7b3c485f16698349d1912037a41e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
plugins may pull in additional qt modules which may require additional
plugins in turn.
Change-Id: I22264b39c1397666b2dc9079048ed1fc64aa84d9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
while we already linked the plugins for our own private deps, we failed
to do so for our transitive deps.
this also fixes linking qml plugins if qml is linked only indirectly and
privately.
the code for setting up rpath-link is slightly refactored as a side
effect, with no functional change.
the code for setting up rpath now also sees the longer list of
dependencies, but that's irrelevant, as qtcore always ends up among the
direct deps anyway iff any non-bootstrapped modules are used.
Change-Id: I90dca81a2836c6191ce5d092e16bf7660ee820bc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
static plugins must be actually linked into the target whenever it is
not a static library itself.
apart from fixing qml plugin linkage, this also provides a more generic
fix for the already fixed linking of activeqt controls.
Task-number: QTBUG-28215
Task-number: QTBUG-55279
Change-Id: I9661369bf3dfc6bcf3a5ed563e6716eb3ef6e76e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... instead of the directory it resides in, to make it independent of
the user's fs layout. this makes logs more comparable, and little else.
Change-Id: I0ab3e968dad74ef86577f388c8ca1557e3c17ce4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this was introduced in 60e5a1c8 for no apparent reason.
Change-Id: Idcbc6df3df4e4846c76b3e4215d753a1c97e2eec
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
now qmake is the last command called by the unix configure script.
as it happens, this was already the case in the windows script, but only
because it didn't print these messages at all, which it implicitly does
now.
another effect of this is that repositories outside qtbase will now also
get the installation note in modular builds, which makes sense.
Change-Id: I567146936b216185a8e0f61e445222215608bf13
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The macOS and iOS version bumps were already proposed, and bumping
up tvOS and watchOS by one version since all original devices that
ran tvOS 9 and watchOS 1 can run the latest versions and given
the upgrade cycles and TP status of these platforms in 5.8, there
is not much point supporting any older version.
Change-Id: Ib01035054291f5bcd18d15a4f27ad33922076851
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
we don't want to do the (possibly interactive) license check when the
command line is not valid.
Task-number: QTBUG-18459
Change-Id: I68c3b7ed4646e49865922ab5612f971930698356
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
log a message in all unsuccessful exit paths.
Task-number: QTBUG-57217
Change-Id: I8b0f2685d327da583c3e42c8149327e05b2a66cc
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
beyond this point, simulator_archs is only used to determine from which
one of the lists the remaining arch came from (and device_archs is
actually never used again). the lists are assumed to be mutually
exclusive, so truncating them won't affect in which of them the first
element of their concatenation is found.
Change-Id: I4736ed7e51f6623efa6bd37892ab1fcf8c83ae8b
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
there appears to be no particular reason why this ended up in sdk.prf,
and it has become an actual problem now that the sdk is resolved from
default_pre.prf already, making it impossible for projects to override
the deployment target.
Task-number: QTBUG-56965
Change-Id: I8e319d10cdfb95acc1da1f431c8b8d4f76d1168e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
uikit already implies !host_build, as host builds are executed with the
host spec. and the only darwin alternative to uikit is macos.
Change-Id: I6b47d68bad5d4427640901ff1e32dacf9a4e352b
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
this is mostly for appearances (as evidenced by everything working
despite it being missing from some specs), as the variable is just a
fallback for moc.prf's automatic detection.
Change-Id: Ie4af24c02ec03aaa1810281d1bb6876ea38cedf8
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Disables escalating the implicit fallthough warning to an error, since
Qt is not yet free of unmarked implicit fallthroughs.
With this we can clean the code in the dev branch instead of in 5.6 and
5.8, and only backport bug fixes.
Change-Id: Id30ee21b77de6defcb7d5bb1e05e86c0db098481
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make it depend on the corresponding Private target of each
dependency. This way, user code can write
find_package(Qt5Gui REQUIRED)
add_executable(hello hello.cpp)
target_link_libraries(hello Qt5::GuiPrivate)
and get the private include directories for both Qt5Core and Qt5Gui.
Don't create the Private target if any of the private include
directories do not exist. This way, if user code uses one of the
targets, CMake will issue an error if the private include directories do
not exist. Unfortunately the error is somewhat cryptic (eg, 'the
"Qt5::CorePrivate" was not found'), but this is still an improvement
over an error at compile time.
This is an improvement on the situation described in QTBUG-37417 using
Modern CMake features.
Change-Id: I034f8216c3ec64d1a3309682456a713cac9bf854
Reviewed-by: Kai Pastor <dg0yt@darc.de>
Reviewed-by: Stephen Kelly <steveire@gmail.com>
Since we can tell the MSVC version from the compiler now, each of the
qmake.conf files is now the same, so let's just have "win32-msvc" and be
future-proof. Likewise for win32-clang-msvc.
qplatformdefs.h was already common.
Since we can't obtain the MSVC version from the unified mkspec name any
more, I dropped the warning level during the qmake bootstrap to reduce
the number of warnings that need to be disabled from compiler version to
version.
There is no point in keeping the old mkspecs, but configure will re-map
the -platform argument to the unified spec as necessary, to keep
existing configure command lines working.
[ChangeLog][Visual Studio] Qt now has a common mkspec for all Visual
Studio versions, called "win32-msvc". The old names which contained the
version number are now gone (but qmake scopes based on the old names
continue to work). The version of the compiler can be obtained from the
MSC_VER and MSVC_VER variables (for example, for Visual Studio 2015,
those contain the values 1900 and 14.0, respectively). Those variables
are also available with the Intel compiler (win32-icc) and with Clang
(win32-clang-msvc).
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: Ib57b52598e2f452985e9fffd14587c0a77a5c09c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We're asking the compiler anyway, so we can fully use this information
just as well. Note that this actually happens after the spec itself has
been processed, so it was necessary to delay the version-specific flag
handling as well.
Change-Id: Ib57b52598e2f452985e9fffd14587b581d946022
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
instead of hardcoding the compat version in the spec, run cl.exe (which
needs to be around anyway) to figure out what version to emulate.
Change-Id: I6eae97fe9a78f8e340ecdabcdc0d48738497c6d2
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this makes it consistent with the determination of the default
include/library paths. this makes sense, as it's possible to switch the
sdk/toolchain after building qt (within reason).
a side effect of this change is that for compilers which emulate other
compilers, both the real and the emulated version are now made
available.
Change-Id: Icfcc672c0d2e3d1b5e622993c366063d70ad327c
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
static builds of qt have been embedding their qml files via the qt
resource system since qt 5.7, so the code which attempted to deploy them
into mac bundles (introduced in qt 5.2) is useless nowadays.
Change-Id: I830cd2b660f7cab42a46ec8e002a42d9d299b528
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the code was broken since 5.0, as it still hardcoded the version number
4 for the plugin basenames.
wince is not supported any more, so there is no point in trying to
restore the code to function.
at a later point, we'll make QTPLUGIN universal enough to cover both
static and dynamic deployment.
Change-Id: I0911ce4aff7a799dd471d6218e046f13dca6d49e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Adds linux-generic-g++ which can be used for simple cross-building to
well-behaved Linux targets.
Change-Id: I20423249cbcaaf7fc2c65e46b737e682d9222e38
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QPA headers are shipped as private symbols, so they should be marked as such.
This helps distros to check which applications/libraries need recompiling
on each Qt patch update.
Task-number: QTBUG-57060
Change-Id: Ie09d4d10e1edb5127d45a05a3dfa3f4c9dd012f2
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
we pull this feat off by booting configure with a dummy spec. the proper
spec gets loaded subsequently.
note that it was necessary to move the cache loading after processing
the early checks (from which the spec handling is triggered). this is
just fine, as the cache is needed only by tests, which are forbidden at
this stage by definition.
Change-Id: I5120e25a8bf05fb8cc5485fd93cf6387301089aa
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
this moves us another step towards the "outer" configure doing just
minimal bootstrapping of qmake.
a challenge here was that so far, qmake itself needed qconfig.cpp. this
was replaced by usage of a qt.conf file instead of compiled-in values.
however, to make the executable still self-contained, that qt.conf is
embedded into it (by simple appending of a fixed signature and the text
file).
the qmake with the embedded qt.conf is not used for the qt build itself,
which instead relies on the qt.conf in bin/ as before. however, due to
the missing built-in values, this file now needs to contain more
information than before. but except for a minimal version that is needed
to start up qmake/configure at all, that file is now also generated with
qmake. as some of the newly set up properties are subsequently used by
configure itself, qmake gains a (deliberately undocumented) function to
reload the qt.conf after it's fully populated.
unlike the old implementations, this one doesn't emit redundant qt.conf
entries which match the hard-coded fallbacks. omitting them leads to
leaner files which are more comprehensible.
Started-by: Paolo Angelelli <paolo.angelelli@qt.io>
Change-Id: I4526ef64b3c89d9851e10f83965fe479ed7f39f6
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
in its current form, it was introduced only in 5.7, mostly as a side
effect of -external-hostbindir (which is now handled differently).
it only ever worked for the macOS and MinGW specs, as a side effect of
them supporting -sdk and -device-option (for good reasons), and was
supported only by the unix configure. it's not believed to be really
useful and complicates matters somewhat, so get rid of it again.
should it ever become actually relevant, it can be re-introduced
properly, probably along with a -host-sdk option for macOS.
Change-Id: Ib078469ea39deb821c7b6a8c67fda9e1a95fedf5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
instead of letting the specs validate themselves on each call, let them
only define a callback for use by the verifyspec configure test. this
is somewhat faster, and allows them to be loaded before qdevice.pri is
populated.
Change-Id: I2b60d006b33bbf42c28949f10ad429520ed32f46
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
its only consumer is qt_tool.prf, which is an internal api.
Change-Id: Iae90b079c5af60efad2ded70d6ea481212e5353a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
... where it actually belongs, as it should work in each repo in a
modular build.
Change-Id: I5463f0bcacb239900bed0b0f7be9cf32a3eab04e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the qmake bootstrap uses some of the options, so the configures still
read config.opt for their own purposes, but the general handling is
entirely in the new system now.
Change-Id: I2c6c657d4da01c8d520ac74795454747bb224bdd
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this also removes the need for passing pre-processed options via
configure.cfg, so get rid of that.
a somewhat unfortunate side effect is that the android-style-assets
feature had to move back to the top level, as the licensing options
depend on it.
Started-by: Lars Knoll <lars.knoll@qt.io>
Change-Id: Id4d1e0ba18b3e3104400293b8f0c7f2f65e68dea
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This re-fixes commit d72ac3f35f, which
simply removed the #define but did so at the wrong place. Instead of
forcing the macro to be removed, let's simply not have it defined in the
first place.
Change-Id: Ie6dbad9bbbd9488887e8fffd148dd67d9a31b32e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This warning does not make sense. it seems to trigger when in code like
the following in template functions:
auto x = 1, y = 2;
3373: nonstandard use of "auto" to both deduce the type from an
initializer and to announce a trailing return type
Other reports on the Internet indicate that no one understands what
triggers this warning and have just worked around it. Additionally, the
same warning exists on other compilers with the same text, so it's
likely come from the EDG front-end. This has been reported to Intel.
Change-Id: I73fa1e59a4844c43a109fffd148d45065ab69eff
Intel-Issue-ID: 6000164202
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
[ChangeLog][Platform Specific Changes][Linux] Added support for
cross-compilation for the MIPS CI20.
Task-number: QTBUG-57411
Change-Id: I5be2f53323b1d3c2323cd51064397590c143af1b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Fixes: warning: implicit conversion from 'float' to 'double' to match
other operand of binary expression [-Wdouble-promotion]
Task-number: QTBUG-57068
Change-Id: I897a341aca83873bc6abd256a82a3b9f09409833
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In VS builds the default name is the first word of the command, in this
case "cl". Use the generated file name instead.
Change-Id: I8f0039eeae045f8b9a13caea8bd3e338bbe2ed17
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
excise knowledge of QTREPOS from qt.prf - this is a private variable of
the qt build system which the public functions should not know anything
about.
instead, move this handling to a function in qt_build_config.prf (where
QTREPOS comes from in the first place), and call it from qt_app.prf and
qt_example_installs.prf (which should be the only consumers within qt).
qt.prf now also checks that the qml install dir actually exists, which
is not the case during a modular prefix build of qtdeclarative.
not really incidentally, this fixes modular static builds of
qtdeclarative.
Task-number: QTBUG-57308
Change-Id: I31465b9cd400483264fc236934c6f9f26a5fdd73
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
we can't use $(QMAKE) after all, as this breaks with the visual studio
generator. so massage $$QMAKE_QMAKE into the final form manually
instead.
supersedes 591d9588f in amending 2b6bcd5ff.
Change-Id: I8c7a6c43f9668d88c1cc968dbf5614240f16239a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
gcc-base-unix.conf must be included before clang.conf because
clang.conf doesn't set all the needed flags.
Change-Id: I71f95732d0d245096b575c91610800d91c6aa5d7
Reviewed-by: Vyacheslav Koscheev <vok1980@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This is a backport of 6cc02ce6c8 from 5.7.
In a parallel build we may end up copying the qmldir file at the same
time, which doesn't work on Windows due to file locking. Apply the same
guard for the copying condition as in commit
770a0c91f3.
Task-number: QTBUG-57153
Change-Id: Ibac759b16cebaf04f5d2f785211b62071aa656a8
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
the variable is converted to a format suitable for makefiles only after
the project was read. to access it, one needs to use the exported
makefile variable $(QMAKE).
amends 2b6bcd5ff.
Change-Id: I5eddff4bebbbcf461b565d5033d17a8daff1e6f4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This commit re-enables support for OpenVG in Qt, but not in the
same way as in Qt 4.8. The first part is about adding a test
and using the new configure system to enable OpenVG.
There is still support code in Qt for setting up EGL to provide a
surface and context for rendering with the OpenVG API, this commit
enables a path to do so.
Normally to get access to an EGLContext from a QWindow you do so via
QOpenGLContext, but in setups without OpenGL but with EGL and OpenVG
this doesn't make sense (there would be no QOpenGLContext). So the
intended way is to use a QWindow to get an EGLSurface, then create
an EGLContext directly (without going through QPA).
Change-Id: I0f75aadbaa3cd006deb7e6fd12cfbb574870fba4
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
this is complementary to configure's makeSpec library source type.
this should be sufficient to make QMAKE_USE += {egl,opengl,opengl_es2}
actually work, obsoleting the need for opengl.prf and egl.prf (and the
currently dysfunct openvg.prf).
Change-Id: I2f7595ac89afa087ea7f0f25060e8e47e6148be9
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Pretty useful when working on Qt itself or just having to deploy
a proper hand-crafted latest greatest to the Yocto-built image.
[ChangeLog][Platform Specific Changes] Added support for
cross-compilation targeting Renesas R-Car H2 (Lager) systems.
Change-Id: Ie359956046b0752a6053f85b81d32550b91ce453
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
now the callbacks don't need to re-export the designated file contents,
which improves the abstraction and removes some boilerplate.
Change-Id: Ifa50313155fc96762025e2610b810ebb71daa373
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
otherwise it's sometimes quite hard to tell it apart from configure's
own messages.
Change-Id: I2f4908344367a9a3ce38e032bf76486fc4552ffd
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this got broken in 2ad4d75754.
however, the new configure system operates from the top-level build dir
anyway, so there is no point in messing with the cache as a reference
point to start with - just use OUT_PWD.
Task-number: QTBUG-57120
Change-Id: I69629bf497931574bff8452939170abb1776ab60
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
'use' entries in the tests and libraries sections of configure.json
files should work acrosss library boundaries, so a test in
qtwayland can refer to a library from qtbase.
Change-Id: Ide02b9985be427a27982a422ca84a29b23145bcf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
You can now use 'module.gui' to check whether the Qt Gui module
exists in the current build of Qt.
Task-number: QTBUG-56656
Change-Id: Ic73f162ed0578e07c70e3ec3706f285b6d09a41d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
On Windows cd does not change the drive. So when you are on drive C:
and type "cd D:\data" it will change the directory on drive D: but not
affect your current working directory.
To also change your drive you have to provide the parameter /d on
Windows, so "cd /d D:\data" will also change the drive.
Task-number: QTBUG-57080
Change-Id: Ib629879534523982eec693cef725f20a535a1a74
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This strips leading whitespace from asset catalog filenames, which was
causing installation to fail due to incorrectly calculated paths.
Task-number: QTBUG-57090
Change-Id: I80db627262f9d58f4403e2d8ab205bef2113992b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
this actually affects only non-framework Darwin builds - debug-only
framework builds are impossible, and Windows is always debug-and-release.
Change-Id: Ia79dbbefc5750168ebd8967fe4afbe173f55a0d6
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
they were already omitted from the console output; there is no need to
spam the log with them (their completion was not logged, either).
Change-Id: I32c97413d2e6ceb18ee61356855cc6a7fa2222bf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
they have none.
Change-Id: I1e5ffa9960c4fac3c708be4820fb40e7909569c8
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it is counterproductive to clear the log when cached test results are
used, as that makes it hard to determine how they came to be.
-recheck isn't as clear-cut as -recheck-all, as only part of the results
is discarded, and we can't reasonably discard only part of the log. i
opted for clearing the log entirely, as having both the old and new
results in the log would be probably quite confusing.
Change-Id: Ibb391f2ba2ea86d73c23365d46cc66ed8a2158d6
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the new configure system doesn't use this type of caching. also, it's
invoked via qt_parts.prf, which actually has the same call.
Change-Id: Ifa1e810e24330b59a1eb9f883eb0500642a212f3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
use precalculated path instead of incorrectly assembling it from
scratch. it accidentally worked when the features happened to be in the
right order, as the iteration variable 'feature' from the calling
function was inherited. however, if the feature was accessed via
dependency resolution, things blew up.
amends 90eee08b3e, which presumably came to be this way due to a missing
adjustment to a refactoring.
Change-Id: I78b0acc0682cfc27a458df014ce14262a65c6241
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The plugin depends on AssetLibrary.framework, which is only
available for iOS.
Change-Id: I798c87b57881210ced8e4a7399c1e45d130ee357
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This was added in 28f5d79316 in
conjunction with CONFIG+=single_arch, but CONFIG+=single_arch on its
own is enough to properly disable unwanted architectures for configure
tests in simulator+device builds now that exclusive simulator and device
builds have been removed for all relevant configurations. This change
therefore fixes the -sdk iphonesimulator build for the upcoming merge
from 5.8.
Change-Id: I57fa2c4f0782a84755a39c6edfce2dcfec554c40
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
users may want to use pkg-config regardless of whether qt itself was
built with it. that's particularly relevant when using binary packages
on macos while trying to use 3rd party dependencies from homebrew.
Task-number: QTBUG-36256
Change-Id: I15e6d0bf5cdaff4274e2d7c07917e97f29157a5c
Reviewed-by: Massimo Callegari <massimocallegari@yahoo.it>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Scan lex and yacc sources for dependencies as if they were C source code,
which is close enough to reality.
This will unfortunately result in the generated source files depending on
the generated headers, while it should have been the object files created
from these sources which have that dependency. But qmake cannot do better,
and this is good enough.
Task-number: QTBUG-56507
Change-Id: Ic3e1941bf2e2820bfddf99deba854e1e82f83669
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The "use" option was so far only available for tests, to define that
the test requires usage of a certain library. Extend this to libraries,
so they can also define that running the test for the library requires
usage of another lib.
Change-Id: I2749c21e27c08ad6e12040590317c06c97f493db
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
These CONFIG entries are also needed during configure, and preemptively
fixes build errors uncovered by an upcoming forward merge, due to code
restructuring.
Change-Id: I39ae5e0f24bbd43dd3c04225d42cce4edd199094
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This is needed in order to be able to specify a custom location of
the ANGLE libs, and enables us to perform a LoadLibrary of ANGLE libs
by just having the absolute path to QtANGLE.dll as the argument to
LoadLibrary().
Previously, we had two ANGLE libraries: libEGL and libGLESv2. libEGL hard
linked against libGLESv2. If we wanted to load libEGL from a custom
location, we couldn't load libEGL by calling LoadLibrary with the absolute
path to libEGL, because libEGL had problems finding libGLESv2. One
solution to that could have been to call SetDllDirectory() with the path
to the ANGLE libs before calling LoadLibrary("libEGL.dll"). Since the DLL
directory would point to both ANGLE libs, this would ensure that the libGLESv2
was also found. Unfortunately, this approach is not thread safe
(SetDllDirectory will affect all subsequent LoadLibrary(Ex) from the same
process). Therefore, we chose to merge the two libraries into one to
circumvent the whole problem.
At the same time, this patch also enables loading of two different ANGLE
libraries into the same process at once without renaming them: This was
not possible before because libEGL hard linked to libGLESv2.dll. When
libGLESv2.dll was already loaded, the second instance of libEGL would
simply link against the already loaded version of libGLESv2.dll.
This behavior is documented in the LoadLibraryEx documentation on MSDN:
"If the string specifies a module name without a path and more than one
loaded module has the same base name and extension, the function returns a
handle to the module that was loaded first."
Change-Id: Ic1d886ba802be72ddcf01235bafaedcef662762e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
... and use that variable in qt_configure.prf to find the pkg-config we
detected during qtbase configuration.
This is required for modules outside of qtbase being able to use
pkg-config to configure external libraries.
We do not use the PKG_CONFIG variable any more, as that interferes with
the $$pkgConfigExecutable() function, which some Qt modules still use.
Change-Id: I8886a266207e04301009fe8207c16b02c5455b2f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If the application's Info.plist contains the key
'NSPhotoLibraryUsageDescription', we know that we can safely link in
qiosnsphotolibrarysupport without violating AppStore requirements.
This is a simple feature that doesn't introduce additional qmake
API for doing app deployment with optional iOS QPA plugins.
[ChangeLog][iOS] Starting from iOS 10, Apple requires all apps
that need access to photos to have the key
'NSPhotoLibraryUsageDescription' in the Info.plist.
Therefore, to get the same support in Qt (when, e.g., using
a file dialog), the Info.plist assigned to QMAKE_INFO_PLIST
will need this key as well.
Change-Id: I7a93afe24b589cad96d5a1d9e2a155ad1671178a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
QT_FOR_PRIVATE should end up in QT_PRIVATE instead of QT after being
recorded in the private module pri. otherwise it's added to LIBS and
becomes part of the library's (and thus also the public module's) link
interface. after the fix, only the (semantically redundant) resolution
of qt module dependencies will add the private deps, and only when the
private module is explicitly requested.
Change-Id: I3378457013cad5fa611a22ccbe184e6aa675a2ef
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this is a bit easier on the backwards compat code in qt creator, which
needs to merge and then de-duplicate the lists itself.
Change-Id: I79f9319c26af541f5efa85700878e7ddbd00e2b7
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
since 9ff1310af, the variable's contents are simply added to SOURCES,
and the variable is not cleared. and qmake does not de-duplicate ...
Task-number: QTBUG-53905
Change-Id: I3e551d21cbbd2d0cbfbf7aa7efaa5babac112f9d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Consistent with other Unix platforms, and internally consistent between tests,
as a lot of tests were already applying CONFIG -= app_bundle manually.
Change-Id: Icd2b7e1c08015b26137af60ff82fddbc753f0ff4
Reviewed-by: Jake Petroules <jake.petroules@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>
QTPLUGIN.<foo> is better used with valid variable names, which is not
the case when the plugin type contains slashes (plugin subtypes) or
dashes (just so). normalize these chars to underscores.
Change-Id: Icc93d952b93fef342e2fc93f20e9c5dd010dd734
Reviewed-by: Jake Petroules <jake.petroules@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>
the code got factored out to an own toolchain.prf file, which is
load()ed from default_pre.prf, so no change at first.
however, on mac, we shadow toolchain.prf, and make it load() sdk.prf
first.
a side effect, it has become harder to disable the use of an sdk
altogether: putting CONFIG-=sdk into a project file or the qmake
command line has no effect now. instead, it's possible to put it into
.qmake.{conf,cache}.
to make it simpler again, it's conceivable to finally add qmake -pre,
which would allow setting variables before default_pre.prf is executed.
take 2: there was nothing wrong with the original patch, but in 5.8,
CONFIG+=simulator_and_device moved from qconfig.pri to various prf files
that would do it according to the simulator_and_device configure
feature, which would be way too late for the "pulled ahead" sdk.prf
loading. as simulator_and_device is now gone entirely, it is safe to
re-apply this patch (mostly) as-is.
Task-number: QTBUG-56144
Change-Id: I6cf484982eaed8af39f7a539c60f5a087a299914
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
A separate flag is no longer needed now that simulator and device builds
are not exclusive any more (*) - both 'simulator' and 'device' being set
at the same time is a sufficient indication (uikit/default_pre.prf sets
this up according to the simulator_and_device feature and the
QMAKE_MAC_SDK variable).
(*) xcodebuild mode actually still uses exclusive builds, but this is
activated locally in uikit/default_post.prf, and uikit/xcodebuild.prf
implements the actual build passes manually anyway, so this change does
not affect it.
Change-Id: Idf173a7bfeb984498d3a49ed6b8d1a16da6c2089
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
project files may not override QMAKE_MAC_SDK any more, which seems to be
no big loss. it is still possible to override the sdk on the configure
command line (but note that this only ever worked for the target sdk).
this simplification is preparation for subsequent changes.
Change-Id: I3201629af132fa3938b13577854f3b19857a1b5a
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
so far, we have been delaying the linking, because we didn't want to
make the monolithic platformsupport module pull in spurious
dependencies. however, now that the module was split, there is no need
to play such games any more.
a nice effect of this is that the hideous qpa/*unixfontdatabase.prf
files disappear, and finally freetype_dependency.pri also becomes
trivial and is thus inlined.
Change-Id: I255376d592625542310a31222eb6ac965943df99
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
public uses of external libraries are automatically transitive now, so
we can remove some parts which were only meant to pull in transitive
dependencies manually.
this is particularly good for includes() of parts of QtPlatformSupport,
which actually redundantly pulled in the library's sources.
this required making the freetype and fontconfig dependencies public,
which is ok, as in the end, they are used only by platform plugins, so
there is no point in making them private, as plugins are not linked
against anyway (except statically, but there public vs. private doesn't
apply anyway).
Change-Id: Ia2a32f50dc0f8472285675a0903e6ecd142a03b2
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>
for that, qt_help_lib.prf gains the ability to write "external module
pri" files that contain suitable information for QMAKE_USE.
these files have a bunch of limitations:
- they are not installed, because a) they are not relocatable and b) the
helper libs' headers are not installed, either
- it won't work with qmake -r, which is ok, as qt5 does not build with
qmake -r anyway
- deps are not transitive, neither at build nor at use time
the freetype, harfbuzz-ng, pcre, and png helper libs have been adjusted
accordingly, and their uses replaced with QMAKE_USE instances. this also
allowed inlining the now trivial {harfbuzz,pcrc,png}_dependency.pri
files. freetype_dependency.pri remains due to its funkiness.
Change-Id: I16890eecb122e34ec49f3d3e68380d1ea71a198a
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
use fontconfig feature directly instead.
easier to understand data flow, and less noisy compiler command lines.
Change-Id: If80af4b08933049d553df685b41422d15e1e4f5c
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
the order of the arguments passed to addExclusiveBuilds() determines the
name of the CONFIG flag which actually enables the mode. that is
historically fixed to iphonesimulator_and_iphoneos and we cannot just
change the order.
to get around this, add a new "overload" of the function which allows
specifying the flag independently from the order of the builds, and make
use of it in ios' resolve_config.prf.
amends d2b4a789c.
Change-Id: Ia3fabea0c0c30beae680b57e75bdcdf35ef6503d
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>
it makes no sense to version them, as they contain only #defines anyway.
it also removes the need to special-case their location in shadow builds
with pre-synced headers, which we actually failed to do anyway.
Task-number: QTBUG-56286
Change-Id: I4ea717f7be56494cfea0572389bea173d7470b6e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
You can place the export macros in the namespace declarations on ELF
systems and that will apply to all declarations inside that scope. If a
namespace is exported like that, then we should mark it for versioning
too.
Note that the exporting doesn't happen for declarations in other scopes
of the same namespace, even though the findclasslist.pl script will mark
everything in that namespace. This should not be a problem.
Task-number: QTBUG-55897
Change-Id: I371f5b01e24a4d56b304fffd147274778b980ad2
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Add conf files for -device qmake switch. It consists of two common
pre/post includes for FreeBSD-base device. "freebsd-generic-clang"
-device option for generic cross-compilation target, with bsdfb as
default platform and freebsd-rasp-pi-clang option for Raspberry Pi
(up to version 2) with OpenGL ES2 (eglfs) support
Change-Id: I45d91c0512f60f2be438ce46e0485844c341188a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
the field was "over-expanded", which led to always querying the
non-existing source with an empty name. this broke the handcrafted
openssl library export which uses the feature.
amends c0cc50520.
Task-number: QTBUG-55530
Change-Id: Id019fcb3e7adcecaf47d7a65820179da1617c0f7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This scheme is needed to define Bluetooth (LE) capabilities on Windows
Phone 8.1. Setting these capabilities is a bit more involved than what
we currently support from qmake (see
https://msdn.microsoft.com/library/windows/apps/dn263090.aspx) but this
way we at least prepare the template for these steps.
On Windows 10 the bluetooth capabilities are set automatically similar
to the way it happens for other modules.
Change-Id: Ib3aa88802c3b421c9c3d02ec4db647cde2191f16
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Previously, manifest files always got processed to perform, e.g., variable
expansion.
This change introduces the 'verbatim' flag for WINRT_MANIFEST.CONFIG to
disable those steps and perform a simple copy of the source manifest.
Task-number: QTBUG-43468
Change-Id: Ie7d4d27376efb3bcf5bc38163496f0a1f1319742
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Split them and add -I flags to INCLUDEPATH and -D flags to
DEFINES. Anything else gets reported as a problem and dropped.
This has the benefit that qmake will automatically use -isystem for
those paths if they lie in a system directory. As a consequence of that,
we won't get any warnings in headers located there. There are multiple
cases of glib, gtk, etc. headers producing warnings (such as enums
ending in comma). This does not fix warnings produced by use of macros
declared in system headers, though...
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: I4b844cb518dbae5ea499811221f9015af985110a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Instead of forcing a static build, configure now respects the
-shared flag and defaults to that.
[ChangeLog][Important Behavior Changes] Qt for iOS now respects the
-shared configure flag, and now defaults to this configuration as with
all other platforms.
Task-number: QTBUG-42937
Change-Id: I9e7b2de8f7f8ba031c2610ff5ac0858e357424bd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is now centralized in configure.pri except where it explicitly
needs to be overridden.
Change-Id: If829d6b5eecf9a5fc403d0a0600d12c9e5781525
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
convert the ugly config.tests/[...]/freetype.pri file into a custom
callback in configure.pri, and reinstate pkg-config use for freetype.
subsequently, use QMAKE_USE for the actual library references.
this fixes in particular cross-builds, as the new configure was not
passing the necessary information to the test any more, so the old .pri
file misbehaved.
Task-number: QTBUG-54911
Change-Id: I5fc9c254334a2675f7db4d54df4c77637e8e2487
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
it's now possible to declare references which don't cause linking (or
cause only linking).
make use of this in the xcb-static library.
Change-Id: Ic429e0a1200b3a333738ea8d8e576ff64b6cac21
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this makes it possible for features added via CONFIG to use QMAKE_USE*,
as default_post.prf is processed before all features in CONFIG.
Change-Id: Id0812a0fb1aa5e658548bd2bc6003234085545e7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The "args" variable would contain the original -spec XXX flags in
addition to the -spec macx-xcode passed in the system command invocation
below. The last use of -spec takes effect, so this code was entirely
ineffective. Consequently, uikit/default_post.prf in the nested qmake
call thought it's still the top-level call and thus added xcodebuild
again, which caused an infinite recursion.
Change-Id: Ie98d8a7f3c1cd875f4a4146af9a66a66b48cc6cb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this is, in fact, not the same as --proxies=system, and the old
configure handles this by putting special cases before the catch-all
patterns. we achieve this by trying the verbatim names (of all options,
which is admittedly a tad inefficient) before applying the -qt/-system
transformation.
Change-Id: Ic85a9d76d6e8ca95b2e1b5566f047f4b7ac38b98
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- generic --* options are defined to be booleans, without the
possibility of having an additional parameter
- -qt and -system options don't exist in the --* form
- --foo=bar options exist only in the --* form
Task-number: QTBUG-55610
Change-Id: Ib0480ac6f479df48045c9de8e854a525862ee363
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
every repo's .qmake.conf is expected to do it already.
Change-Id: I87ed75d80493d8f1c4548c5b9dadfdaf07b86d7e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
this is a relic from the early times of the modularization.
Change-Id: I9ca46fa6457bf9ca207b6be1f0637f0349569ddf
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The order in which exclusive builds are added affects the order of
values in SUBTARGETS. xcodebuild.mk parses the value of SUBTARGETS in
the Makefile and selects the first entry, which would always be
release-iphonesimulator regardless of the build type. This obviously
caused -sdk iphoneos builds to fail.
This patch switches the order of in which exclusive builds are added so
that the entries which are not present in a particular build type are
always added last.
Change-Id: I306d6f7430c1dff3d741a8c5182b7af81d000e7f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
26d44fce3d added support for passing the
configure options to qmake following a "--" argument. This interacted
badly with xcodebuild.prf as the "args" variable would contain the
standard qmake arguments AND the extra arguments following "--"... which
were placed prior to -spec macx-xcode and the path of the .pro file,
causing them to be ignored and thus qmake to print its usage when
attempting to generate Xcode projects for Qt apps on UIKit platforms.
Amends 6a9f38a11d, which fixed the same
issue inside qmake itself.
Change-Id: I3056bd811c2ce958952fec8e05ddef7a063c0646
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There's no reason for this to be separated, regardless of the
support status of i386 macOS builds. Additional architectures may
appear in the future (and currently there's actually 3 - i386,
x86_64, and x86_64h for Haswell CPUs). So this feature could be
used to get combined generic x86_64 and Haswell builds. Some
system libraries appear to have an x86_64h slice in Sierra.
[ChangeLog][Build System] Support for universal binaries on macOS
has been re-introduced.
Change-Id: I1c89904addf024431fdb3ad03ea8ab85da7240ad
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This essentially emulates Xcode behavior for QMAKE_BUNDLE_DATA.
This is mostly for our own internal use. No documentation is provided.
Variables introduced:
- QMAKE_ASSET_CATALOGS
- QMAKE_ASSET_CATALOGS_APP_ICON
- QMAKE_ASSET_CATALOGS_BUILD_PATH
- QMAKE_ASSET_CATALOGS_INSTALL_PATH
Change-Id: I9577415d637f022d05f301c5a0d799483cd2a963
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this makes build dirs consistent with install dirs, which fixes
launching tests, examples, and build tools in some configs.
unfortunately, this makes prefix builds slower and their build dirs
bigger due to the DLLDESTDIR implementation being stupid (QTBUG-11435),
but i'm not inclined to fix that now. it isn't actually worse than for
non-prefix builds, so whatever.
Task-number: QTBUG-54438
Change-Id: Idbd034620e95cb23f7699d243678c4e9fa6353ac
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
32-bit Qt for macOS is now deprecated.
Change-Id: Idda4f4b3d48c58afae3932e7802bcf82cc75d3aa
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This makes use of the new -quiet option in xcodebuild 8 to reduce the
noisiness of output when make is invokved in silent mode.
Change-Id: I3730dddcc1d9dae329b5ff254448533cdd573a30
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
5971b88e is not needed in new configure.
This merge also reverts "fix QMAKE_DEFAULT_*DIRS resolution with
apple SDK", 2c9d15d7, because it breaks iOS build with new
configure system.
Conflicts:
mkspecs/features/default_pre.prf
mkspecs/features/mac/toolchain.prf
mkspecs/features/toolchain.prf
src/dbus/qdbusconnection.cpp
src/plugins/sqldrivers/mysql/qsql_mysql.cpp
src/sql/drivers/mysql/qsql_mysql.cpp
src/widgets/widgets/qmenubar.cpp
src/widgets/widgets/qmenubar_p.h
tools/configure/configureapp.cpp
tools/configure/environment.cpp
tools/configure/environment.h
Change-Id: I995533dd334211ebd25912db05b639d6f908aaec
This macro expands into a static_assert and can be used to
trigger a compile error if a certain feature is not available
when trying to compile some code.
This is especially useful to protect against accidental inclusion
of headers that implement functionality related to a feature.
Change-Id: I456c55b989ce5f35f3af0e13c1886a85c23dfe29
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
the code got factored out to an own toolchain.prf file, which is
load()ed from default_pre.prf, so no change at first.
however, on mac, we shadow toolchain.prf, and make it load() sdk.prf
first.
a side effect of this is that project files may not override
QMAKE_MAC_SDK any more, which seems to be no big loss. it is still
possible to override the sdk on the configure command line (but note
that this only ever worked for the target sdk).
it has also become harder to disable the use of an sdk altogether:
putting CONFIG-=sdk into a project file or the qmake command line has no
effect now. instead, it's possible to put it into .qmake.{conf,cache}.
to make it simpler again, it's conceivable to finally add qmake -pre,
which would allow setting variables before default_pre.prf is executed.
Change-Id: I149e0540c00745fe8119fffd146283bb214f22ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... to the new qmake based configuration system.
This removes the old qfeatures.txt (distributed over configure.json
files) and qfeatures.h (distributed over qconfig-<module>.h files).
qfeatures.prf is gone without replacement, as attempts to use it would
lead to followup errors anyway.
Change-Id: I1598de19db937082283a905b9592d3849d2199d0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
"description" suggests something slightly longer.
this may seem like a gratuitous change, but the upcoming replacement of
the old feature system clarifies makes it seem much less so.
Change-Id: Ibe702e01cb146b59127bf1f990b4acaef1c61d55
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Move the different parts of configure.json/.pri into the libraries where
they belong.
Gui is not yet fully modularized, and contains many things related to
the different QPA plugins.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: I6659bb29354ed1f36b95b8c69e7fce58f642053f
Reviewed-by: Lars Knoll <lars.knoll@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>
Ignore everything that after the initial period separated numbers.
Change-Id: I376b154ff0ab6e3877223ec1383ed4708ecd2164
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
For platforms which require packaging the testdata into the application
resources, the BLACKLIST file needs to be added. Otherwise it will not
be found during runtime.
Change-Id: I2d5c3b3040b3b268bc73254459b8b902b7fae4e2
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This reduces unnecessary OS conditions in qmake since these platforms
are mutually exclusive, and also opens up their potential for use on
future devices (like carOS(?), which is device idiom '5').
This is also more similar to what Xcode does, as the
TARGETED_DEVICE_FAMILY variable is not platform specific.
Change-Id: I29d209cd8e0779f492bda829008264773e13c75c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This reduces unnecessary OS conditions in qmake since these platforms
are mutually exclusive, and also opens up their potential for use on
macOS to transparently support multi-arch builds like UIKit platforms.
This is also more similar to what Xcode does, as the DEPLOYMENT_TARGET
variables are platform specific, while the ARCHS variable is not.
DEPLOYMENT_TARGET has a use case for being OS specific in qmake (host
tools vs targets), while ARCHS does not.
Change-Id: Icee838a39e84259c2089faff08cc11d5f849758d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This patch moves towards a more sensible layout for UIKit platforms,
where both the device and simulator architectures for binaries are
combined into a single Mach-O file instead of separating out the
simulator architecutures into separate _simulator.a files.
This approach is both more common in the iOS ecosystem at large and
significantly simplifies the implementation details for Qt, especially
with the upcoming support for shared libraries on UIKit platforms.
This patch takes advantage of the -Xarch compiler option to pass the
appropriate -isysroot, -syslibroot, and -m*-version-min compiler and
linker flags to the clang frontend, operating in exactly the same way
as a normal multi-arch build for device or simulator did previously.
Exclusive builds are still enabled for the xcodebuild wrapper Makefile,
which builds all four configurations of a UIKit Xcode project as before,
as expected.
A particularly advantageous benefit of this change is that it flows very
well with existing Xcode workflows, namely that:
- Slicing out unused architectures is handled completely automatically
for static builds, as an executable linking to a library with more
architectures than it itself is linked as, the unused architectures
will be ignored silently, resulting in the same behavior for users
(and the App Store won't let you submit Intel architectures either).
- Removing architectures from a fat binary using lipo does NOT
invalidate the code signature of that file or its container if it is a
bundle. This allows shared library and framework builds of Qt to work
mostly automatically as well, since an Xcode shell script build phase
can remove unused architectures from the embedded frameworks when that
is implemented, and if Qt ever starts signing its SDK releases, it
won't interfere with that either (though binaries are just resigned).
Change-Id: I6c3578c78f75845a2fcc85f3a5b728ec997dbe90
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This is done because a followup patch will cause simulator_and_device builds
to no longer use exclusive builds and so this feature could not work,
but it is not strictly necessary anyways because users do not need to be
able to do this.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: If869fbfea776751553c352c2d652edf745a3638d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The actual blocker for precompiled headers is not the iOS/tvOS/watchOS
platforms, but the way qmake handled multiple-architecture builds on
Apple platforms.
This patch allows multi-arch builds to be performed while using
precompiled headers.
Since df91ef3d6c55692a0236f67b6c6b134a3bf84098 (April 2009), Clang has
had support for PCH files in the driver, which allows to use the
-include flag to automatically translate to -include-pch. We can then
take advantage of the fact that the -include option is allowed to not
be separate from its argument, which lets us take advantage of -Xarch to
specify a per-architecture precompiled header file.
This is done through some magic in the qmake Makefile generator which
"multiplexes" the PCH creation rule across multiple architectures and
replaces a series of tokens with the proper precompiled header paths
and architecture flags at usage point.
Change-Id: I76c8dc9cda7e218869c2919f023d9b04f311c6fd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Actually enables headerpad_max_install_names in the darwin-g++ mkspec
as previously it was (presumably accidentally) cleared.
Change-Id: I4b2e5a0dcf38658cfe35bc0e5f24769c80f4d877
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Now QMAKE_RPATHDIR also includes @executable_path and @loader_path
on Apple platforms, and omits any others on iOS, tvOS, and watchOS
since they can't use paths outside the application bundle.
Change-Id: Ia8f76ebcddd51f44eca482a51ce1710369c8df10
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
iOS was excluded in 09aeda21b9, probably
unnecessarily. The build has been found to be warning-free.
Change-Id: I81de2fff40938b6ab9f7a6a5b9f08f8a8baadb16
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
