The freebsd-g++46 mkspec was intended to specifically use gcc 4.6 from
FreeBSD ports collection. However, the ports collection moves its
"standard" gcc version and uses symlinks to the standard commands
(e.g. gcc -> gcc48) on installing gcc. The current gcc in ports is
4.8.5, so the mkspec is not useful at all.
Change-Id: I041325d05c7dc3f47f4a774d6f46ba24a601bf3e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On FreeBSD, the gcc manpages until Release 5.1 mentioned using
the -D_THREAD_SAFE define when using -pthread. This has been obsoleted
and the gcc manpages from Release 5.2 onwards have this removed.
Now we finally remove this historic relic here, too.
Change-Id: I00a5b688c56f46b938c0806fb44b72d5afe5079e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By using commmon/gcc-base-unix.conf and common/g++-unix.conf most of
the contents of the qmake.conf for OpenBSD can go. The QMAKE_LFLAGS_UNDEF
are reset because the linker can't handle environ in libraries, which is
only added to libc in OpenBSD 6 (http://www.openbsd.org/faq/current.html)
even when explicitly adding -lc to QMAKE_LIBS.
See
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151102/309783.html
for similar questions on using -Wl,-z,defs instead.
Change-Id: I6c725fb3bc7ae63270912b07f230a480c9157dfd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By using common/gcc-base-unix.conf and common/g++-unix.conf most of the
mkspec details can go, leaving us with a minimized qmake.conf.
Change the default X11 location to point to /usr/X11R7 after NetBSD
switched to X.org in Release 5.0 by default.
Also change the default location for addon software on NetBSD, it uses
pkgsrc as its ports system which installs to /usr/pkg by default (the
default value for $LOCALBASE of pkgsrc on NetBSD), see
https://www.netbsd.org/docs/pkgsrc/using.html chapter 4.1.
These default values mirror the current state of NetBSD usage to get
the prerequisites to compile Qt with a minimum amount of configure
parameters.
Tested with NetBSD 7.0 using gcc 4.8.4-nb2 (system compiler)
Change-Id: Ic50757af9f070c0383c7356302e7e7686f031740
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
LIBGCC_PATH was used before we initialized it, somehow it magically worked ...
Change-Id: I0a9a748ffbfc641f60736b0cf85d23f499b64e66
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Add -lexecinfo for backtrace(3) on NetBSD and OpenBSD. Without,
qlogging.cpp linking will result in undefined references to backtrace
and backtrace_symbols. The behavior required is identical to FreeBSD so
no additional fixes are required (see src/corelib/global/global.pri:41)
Change-Id: I3cfd1d75f1fb5b8505c08a880f91e7b39a5a650d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
FreeBSD 9.3 is still supported and uses gcc as the default
compiler, therefore FreeBSD ports require patching the mkspecs
back. To avoid patching, move the mkspecs back to the right
place and adapt the path in the qmake.conf/qplatformdefs.h
[ChangeLog][FreeBSD] The freebsd-g++ mkspec was moved back and no
longer requires the "unsupported/" prefix, matching the FreeBSD
ports tree, as FreeBSD 9.3 still defaults to using GCC. Users of
GCC that did not previously use the ports patch will need to adapt their
build scripts and drop the "unsupported/" prefix.
Change-Id: Ideda4a33cccf5381000f6f50b6ae92a5c24ba9d4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Having the debug info in separate files is very helpful, especially on
memory constrained 32bit systems. When the debug info is compiled into
the object files, processes can run out of memory when trying to load
them.
Change-Id: I1808a32e855d6a62e17e1b734c511b31db5f03f1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The freebsd-icc mkspec was intended to be used with the Intel
compiler, which nowadays is still only available in version
8.1.038 (https://www.freshports.org/lang/icc/) and for i386 only
while the current version is around 17. On FreeBSD the port
was actually never supported by Intel anyway.
Change-Id: I03b1939be63eef4363bd6b074a6b739365f495ac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
LIBS_PRIVATE is more correct (these shouldn't be part of the public API),
and additionally, using LIBS_PRIVATE also ensures these libraries come last
on the link command, which fixes builds using -Wl,--as-needed.
Change-Id: I9f2e4e78855a30a53ce9013623597b840a2832bd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
While previous SDKs used the form "CE_SDK (CE_ARCH)" in their
configuration/platform names, this is not true fo the Toradex SDK.
Inside Visual Studio the platform is only called "Toradex_CE800"
instead of "Toradex_CE800 (ARMV7)".
In order not to break other SDKs CE_PLATFORMNAME is introduced and
used in the wince80colibri-armv7-msvc2012 mkspec. If the variable
is set qmake uses it as the platform name in its vcproj generator.
Change-Id: Icb501bf6446a9f617745a0d2c7a80b240680b043
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andreas Holzammer <andreas.holzammer@kdab.com>
so far, each module had to do it in its .qmake.conf. by now, all modules
have been adjusted to the expected structure, so we can enable it
centrally.
Change-Id: I16b4e7581e51bfc54e71d2f7f852858ae0b47281
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Other popular specs have this as well.
Change-Id: I44245f37857d476b9ee53ecad021261b94214b2f
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
Reviewed-by: Louai Al-Khanji <louai.al-khanji@qt.io>
don't pretend that these two flags can be set separately - the
configures set them in tandem.
Change-Id: Ib0beae0152de09026d4627fd3ae0feabd9ce1b81
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When compiling on Windows to for example Android, we may be using the unix
generator, but the make command may be mingw32-make.
Task-number: QTBUG-53038
Change-Id: If8d1e1bea733cf1b4ed837c423a34ecfb3cafd1f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We don't know why it works, but we've been told that it fixes
some builds and we have no reason to think it will break others.
Task-number: QTBUG-52998
Change-Id: Iacaa1fb3c49e4d7aafd4167e591ff3724489872e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
our zlib header includes qglobal.h, so we need the qtcore include dirs,
and qtcore is also where the actual code is compiled into.
Change-Id: I09f530a1b4e6160438215a6d7223c0771ce94f05
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
this makes it fully consistent with INSTALLS.
note that this also removes the file name from the target path when
copying files, also for consistency.
Change-Id: I69042c9aa1e2cc81f8ff982343ba25688a04abfd
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
- QMAKE_FILE_IN_EXT as an alias for QMAKE_FILE_EXT, for consistency with
QMAKE_FILE_IN_BASE
- QMAKE_FILE_IN_NAME to make pairing _EXT/_BASE to get a full name
unnecessary (finally ...), and make use of it
- QMAKE_FILE_OUT_PATH, because i'll need it
Change-Id: I3d91ddb84f9cce52a665d562da11d165c92550c8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
newer versions of qt creator understand QMAKE_EXTRA_COMPILERS and
INSTALLS, so there is no need to list the files twice.
Change-Id: Iccf3cc3248daf3422b8c366c2eb2d2f46c5f08d1
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
the host compiler's version is not determined, so we cannot make any
assumptions about its capabilities.
Task-number: QTBUG-53017
Change-Id: I939fd7402b5daac73f2195b9d8763b9008bc7ea4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
this adds file_copies.prf, which understands the variable COPIES, which
works analogously to INSTALLS.
i've been holding this off for a long time, as it is not without
caveats. however, similar hacks are proliferating all over the code
base, so it's time we formalized it.
in fact, it's the easiest way to fix some nasty shadow build problems,
which is why i'm adding this on the stable branch.
Task-number: QTBUG-52256
Change-Id: Icbe3b9fbb79c952546aad2d467a438d3a69d749f
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This makes the -separate-debug-info configure optional functional, which
generates dSYM debug info bundles for Qt libraries on Apple platforms.
Task-number: QTBUG-37952
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: Ia247674740bf450130a15db926df07fa9007e2ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
it doesn't appear to be referenced in any way, either.
Change-Id: Ifd30b435e3e628cd5e48ae24e9aef01c662d6d61
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Incidentally, this introduces QMAKE_RESOLVED_BUNDLE, which can be used
to determine the path of the bundle wrapper itself as well as the
executable target.
This is necessary for a subsequent patch adding support for
-separate-debug-info on Apple platforms.
Change-Id: Ia11430026b8e3f171e5db6677b190b8356832805
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
We should really start using -L=/foo and -I=/foo inside of sysroots,
this test was preventing us from doing so (while arguably buying us
nothing).
Change-Id: If6e67631c585493871231e5d8a9354fa72e07343
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
this flag specifies that the plugin does not track a qt module. this is
entirely unrelated to whether the plugin should be versioned.
amends f54a3d783.
Change-Id: Ibd3e9bedf488dc58e6354ccf7dd33d974e5f52c2
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
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>
Using Visual Studio a user very seldom wants to disable the automatic
invocation of windeployqt. Hence switch from opt-in behavior to opt-out.
This also fixes first user experience to invoke qmake –tp vc and then
hit run on examples.
[ChangeLog][Platform Specific Changes][qmake] qmake-generated Visual
Studio projects now automatically invoke windeployqt by default.
Task-number: QTBUG-52008
Change-Id: Iee1607269c38c7f6c726f554978ac05477bebe5e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Adapt the mkspec which was forgotten in change
b0ec05f27b.
Task-number: QTBUG-48431
Task-number: QTBUG-51686
Change-Id: Ie95e650de8b7a7027979ec637fb77c7f0357a598
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
it's likely that these will be wrong, and the bootstrapped tools usually
don't need them anyway. should they turn out necessary after all, we
need to add -H* variants of the flags.
Change-Id: I15c54c5e25d20ebd474073a530f00254842f515d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
it is important that the flags coming from the current qt build appear
first, as otherwise a pre-existing qt installation may interfere with
the build.
the windows configure does not have any of this magic to start with.
Task-number: QTBUG-6351
Change-Id: Iacc1d9b5aa9eed9a5f0513baef9f6c6ffcef0735
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
unlike speculated in 2fe363514, this is not a workaround at all: it
causes that libraries' public link interfaces (LIBS) are exported in the
first place. unlike with staticlib, this does not export LIBS_PRIVATE,
so it wouldn't even be a particularly effective workaround for rpath
brokenness anyway.
the problem was pretty well hidden by the qt module system, which at the
level of libraries is pretty redundant with the .prl file handling,
which shows just how stupid the whole "design" is.
unlike before, we now enable explicitlib for all libraries, not just qt
modules - we enable create_prl for all of them as well, after all.
an immediate effect of this change is that it fixes linking on RaspPI:
the qtcore headers make the user code require linking libatomic, so we
must add it to our public link interface.
Task-number: QTBUG-51621
Change-Id: I5742c88694db8e8a9b79d17222dc6df2b38e5ab2
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
There is no test for c++ standard support for the host build
(only for the target compiler/build) which leads to trouble
in some cross compiling environments (old host compiler, new
cross compiler):
g++: error: unrecognized command line option ‘-std=c++1z’
So disable c++ standard compiler flags unconditionally for host builds.
Task-number: QTBUG-51644
Change-Id: Ifb3042e125fe199a7e081740d1171d26ccacf0c5
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>
This header defines "interface" which will break compilation of dbus.
Change-Id: I16fa35f822adca14304aa827b047358409d4a150
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Testcases and benchmarks are rather different entities. You won't usually want
to run benchmarks in the same environment you are wanting to run tests in,
so this feature allows to differentiate between the two.
We also add a "benchmark" make target (similar to check), which runs all
configured benchmarks.
Change-Id: I33759ce44c34e42a6a3a88f34e7b9c4372380721
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
`ar' tool from latest binutils shows warning:
ar error: `u' modifier ignored since `D' is the default (see `U')
Warning message includes word "error" so QtCreator processes it as
error in UI.
`ar' command-line option `u' might be dropped safely because it is
unnecessary. Option `c' is added to suppress extra `ar' warnings.
Other build systems are also affected. For example, automake:
https://bugzilla.redhat.com/1155273
Change-Id: Ia378b720503d93b0c0c12ae7a5f38f4d7c32eee5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The win32-g++ mkspec is not based on gcc-base, so
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO is not inherited. Therefore,
-release -force-debug-info would build with neither -O2 nor -g.
Change-Id: I4e97cb08f577062dd342fb3e91c02adfd636a310
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
instead of unsetting the flag later on, don't set it in the first place.
Change-Id: Id448500b02b5c3e1dc7c332cc178a84c7fd2cfdc
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
this has multiple consequences:
- we do sane DESTDIR replacement for debug_and_release builds, fixing
QTBUG-47313
- we don't create debug/release subdirectories, fixing QTBUG-47639. this
only makes sense given the complementary call of $$qt5LibraryTarget()
- we patch up the .prl files upon installation
Task-number: QTBUG-47313
Task-number: QTBUG-47639
Change-Id: Id409bbd26781a773409b94835ab6b97e71569322
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Modern FreeBSD doesn't come with GCC by default anymore and doesn't even
provide the "gcc" or "g++" falback that OS X does. So there's no point
in keeping the freebsd-clang mkspec in unsupported/ since it's the only
one that works, or keeping the freebsd-g++* ones outside, as they won't
compile.
I'm not removing the GCC mkspecs because you can still install GCC from
the ports tree.
[ChangeLog][FreeBSD] The "freebsd-clang" mkspec is no longer in the
unsupported/ subdir. If you have scripts you use to build Qt, you'll need to
update them to say -platform freebsd-clang or remove the -platform argument.
Change-Id: I7a9e11d7b64a4cc78e24ffff142dfc11d3aabb1e
Reviewed-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The feature is enabled by CONFIG += unsupported/objc_namespace,
but can be easily integrated into other build systems such as
CMake or native Xcode by modifying the LD and LDFLAGS equivalent
for each build system.
This is a less resource-intensive alternative to using multiple
Qt builds with different -qtnamespace settings.
Note: The feature is not supported in any way, and should be
used with care.
Change-Id: Ibb8ba1159db36efd7106c117cc2210c7e2e24784
Reviewed-by: Martin Smith <martin.smith@theqtcompany.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
10240 describes the first official non-preview Windows 10 SDK. 10586 was
the SDK for the first November update.
Change-Id: Ieb61b944295946eab594b3c7bf234155a67b752e
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
This allows users to add mobile specific features. Also it implicitly
enables support for continuum on Windows 10 Mobile.
Change-Id: I965123722f46df6e84fd279c3bfce478c1172632
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Commit 6e6f27b6 made it possible to set the PKG_CONFIG variable using
CROSS_COMPILE as a prefix. The problem with that solution is that it makes
pkgConfigExecutable() skip the environment setup for pkg-config as well,
as it expects the pre-set command to be self-contained - which it isn't.
To avoid this problem we need to store the pkg-config define in the
device spec in a separate variable.
Change-Id: Id8ae7fb03d9253be55840e23fe73b30815ee86c3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
Without this, any test executable requiring a plugin path from
the environment's QT_PLUGIN_PATH will fail to run since the path is
overwritten when generating the 'make check' command, for example:
QT_PLUGIN_PATH=/path/to/qt/plugins \
LD_LIBRARY_PATH=/path/to/qt/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} \
./test_foo
A prepend config option is used for *PATH to preserve the envvar
value, so use the same option for QT_PLUGIN_PATH. The command above
then becomes:
QT_PLUGIN_PATH=/path/to/qt/plugins${QT_PLUGIN_PATH:+:$QT_PLUGIN_PATH} \
LD_LIBRARY_PATH=/path/to/qt/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} \
./test_foo
Change-Id: I69b43327974915eae52f299fc4001effe93a491a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
one reason to do that is some users' persistence in destroying their
non-prefix builds by trying an installation.
another reason is the fact that qt.pro's relative_qt_rpath is triggered
by the presence of an install rule for the target, which is of course
not helpful when the install dir is bogus.
Task-number: QTBUG-48406
Change-Id: I75f3940be79fcb5b86e34b975b789692423c92cb
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
It only needs stdin now, instead of stdin plus a separate file containing
a list of file names.
Change-Id: I9f3db030001e47e4a4e5ffff1425b76884cc7ca0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
qtAddToolEnv() (via qtPrepareTool()) does not write the tool wrapper
scripts during build passes, while qt_docs.prf (which calls it for qdoc
and qhelpgenerator) was loaded only during build passes. the consequence
was that the makefiles tried calling non-existent scripts.
amends 5418d77a1, sort of.
Change-Id: I64ab573495ca339be4c7b5e8c6848b298b6cb605
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
now that we don't create .pc files for private modules any more, the
conditionals cannot be nested.
amends 6c5d227da, partially reverting aa20e7f9d.
Task-number: QTBUG-49763
Change-Id: I2578c83e0c767b6533abdb26bf4e8bcc8c416ef1
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
judging by the history, this was only ever a workaround for poor rpath
handling. we're supposed to be over that.
Change-Id: I85601493a05a76ead999e707a2d2e9a430610981
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
proper prefix builds don't have the redundant .dlls in bin (the copy
step is simply omitted), so this is broken. the change would have to be
done atomically with making DLLDESTDIR sane.
This reverts commit 9b2e98245a.
Task-number: QTBUG-50065
Change-Id: I9ce0a2d1147a1a2d4bd2f22e619d5c737864a637
Reviewed-by: Romain Pokrzywka <romain.pokrzywka@gmail.com>
Reviewed-by: Tim Blechmann <tim@klingt.org>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
this is just an optimization/clarification: variables which are known to
be never empty (like PATH) can be extended with less convoluted code.
Change-Id: Ib365bbec8301673ed1c874979b4de19bc983dab1
Reviewed-by: Romain Pokrzywka <romain.pokrzywka@gmail.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
the primary purpose is making env var prepend mode work for unset
variables on windows. this is achieved by using a conditional and delayed
variable expansion. however, the latter is disabled by default and can
be locally enabled only in batch files. therefore, write wrapper scripts
and substitute them for the actual commands. we do this also on unix,
both for consistency and simply because the commands look much less
confusing.
this change is slightly backwards-incompatible, as invoking
qtAddToolEnv() multiple times on the same command will now make a total
mess. also, invoking it on a command that contains 'make' macro
expansions isn't a good idea, so testcase.prf needed an adjustment. the
function is an undocumented internal, so Nobody Should Care (TM).
this also reverts 80ebedecf9, as it's obsolete now.
Change-Id: I8394b77868b495abcf27b688996ca74c40b80994
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
That API has been available for WinRT and Windows
Phone for some time now. By using it to get the
machine name and for hostname resolution we can get
rid of some winrt-only code and use qhostinfo_win.cpp
on WinRT and Windows phone as well.
Additionally the required capability was added to
tst_qhostinfo so that this auto test can be run without
any manual editing.
Change-Id: I63fa5521bf8cdb0c919bd5a0100ea977c865622a
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
CMP0054 changes CMake behavior wrt. interpreting quoted arguments in
if() statements. This change ensures that CMP0054 dev warnings are
never emitted no matter how polluted the environment, e.g. even
if the variable ${5.5.1} is defined and no matter whether CMP0054
is set to OLD, NEW or undefined.
Change-Id: Iee008497b333e2db23fb1adbf8b02252314ffa8a
Reviewed-by: Kevin Funk <kfunk@kde.org>
Reviewed-by: Stephen Kelly <steveire@gmail.com>
Recent versions of Qt have apparently added sufficient numbers of
headers that the command lines used to spawn a custom header-
parsing tool, started overflowing Windows' maximum command-line
length.
This change restructures the mechanism to use a GCC-style command-
line arguments file rather than passing filenames all directly
in the argv[] vector.
Although QNX is the usual ELF target whose cross-build is supported
on Windows, the mechanics introduced in this patch happen to affect
all other ELF Unix systems' builds too.
Change-Id: I5a7383cf9f2ebf9dffde8dbfdcdeca888265e085
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
the variable is later re-used by qtPrepareTool(), so the tools used to
build the tool would get excess variables passed.
Change-Id: Ib1bdd2211b4a8615e2be9ba0310822f373f5efb0
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
qtPrepareTool() does it anyway, so this saves repeated manipulations.
for now, this is just nicer, but soon it will be a requirement.
Change-Id: I5184e0e4597c6d5a4d7dd4cc4d81e7f742a79fc8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
QFINDTESTDATA is already prepared to find it there.
Change-Id: I467392786ce6bcfbf1bd0b6079f60c9df06834b1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@theqtcompany.com>
A minimal device spec that can be used to build for arm devices.
Change-Id: I4c9949d8cc59ad534fc7617034f6beb40d6a987e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
If CROSS_COMPILE is set on a Debian multiarch platform, then PKG_CONFIG
should be set the same way as the other cross compilation tools.
Change-Id: Id359a6bbdcbf8a136a0268a82301fc086a2adcfe
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
no idea why it was limited to linux. the variable is already empty on
platforms which don't support it anyway. also, for plugins, it's
consistently enforced as well.
Change-Id: I117f4988a2e301ca98cdc088188d6f8c44ea0ba5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This is needed to be able to use Qt (with dynamic ANGLE) in a plugin
while the host runs a different version of Qt (and ANGLE).
In addition to changing the LIBEGL_NAME and LIBGLESV2_NAME variables
you also need to update the value of the LIBRARY definition in the
.def files for ANGLE:
qtbase/src/3rdparty/angle/src/libGLESv2/libGLESv2[d?].def
qtbase/src/3rdparty/angle/src/libGLESv2/libEGL[d?].def
Task-number: QTBUG-48431
Change-Id: Idd00d039ba3e20cc0ec7496bee36ed1c90383b0d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
[ChangeLog][Platform Specific Changes][OS X] Configure with -no-rpath
will now yield Qt dynamic libraries and frameworks with an absolute
install name (based in -libdir).
OS X package managers like Homebrew install Qt in a fixed location. This
change simplifies deployment for such package managers and is consistent
with the default expectation on Apple platforms for libraries with a
fixed location to also have absolute install names.
While a relocatable installation (the default) also works in this
scenario, it requires all software that depends on Qt to be aware of
this and to embed a suitable RPATH into application binaries (which is
not automatic for non-qmake builds). This might not be true for some
select fallback search locations, but as package managers on OS X tend
not to use those, embedding an RPATH becomes practically mandatory. In a
default Homebrew installation, Qt is configured such that the frameworks
end up in /usr/local/Cellar/qt5/<version>/lib and that will be later
symlinked to /usr/local/opt/qt5/lib, both of which are not searched by
the dynamic linker by default.
Task-number: QTBUG-48958
Change-Id: I4395df98771e06a2ce8a293d11dc755bdc50757f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Visual Studio version specific changes have been added to msvc-
desktop.conf which is not used in WinRT or Windows Phone related builds.
Hence take a similar approach to gcc and introduce msvc-base to be used
by all configurations for common settings.
For WinRT this will only be applied to msvc2015 and later on to not
introduce any regressions or behavior changes for previous versions.
Change-Id: Ib1a4d539d46d788470c00cb5969fee74a803bd67
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
don't install the module .pri file into qtbase even when doing a
non-prefix build.
this has no effect on modules built as part of a top-level build, as
they announce themselves via .qmake.super anyway.
however, modules built separately become unavailable unless QMAKEPATH
or QMAKEMODULES is set. this is deemed not relevant by the original
audience of this feature (the qtwebkit team).
Change-Id: I14c170b2c5dbb99608939aef1a541563d5b755d9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
longer term, the redundant .dlls from the libdir will hopefully
disappear. short term, this is a workaround for CI brokenness.
Change-Id: Ia30173355f3aca222d4ca40e7a38c2cf535bbc03
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The xcodebuild tool only supports the install action for devices, not
for the iOS simulator platform.
Change-Id: I47e8bb7d44962bd4a433a314fa9d315ed3683ca6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
qt_framework and {app,lib}_bundle imply darwin, so there is no point in
testing for it.
Change-Id: I9fe48c26c8e271a5575b17e92df8674d3c3a3204
Reviewed-by: Simon Hausmann <simon.hausmann@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>
