QMakeLibraryInfo uses external data to produce paths. This causes
issues when trying to use it out of the existing qmake environment.
Add data fields that contain the path to the binary that uses
QMakeLibraryInfo and manually specified qtconf.
Task-number: QTBUG-75870
Change-Id: Ic6fa274ede3a9287826ff66c79f155b10d0d455c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We must not pass null pointers to memcpy.
Pick-to: 6.0
Fixes: QTBUG-88780
Change-Id: Ic1d77b4672310a3f6d0d4fbee5f2889e3e4d219d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with
move semantics, its name is misleading. Q_RELOCATABLE_TYPE was
introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE
is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE
by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this
patch should have no impact on users.
Pick-to: 6.0
Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Copy back changes to qmake internals that were done in qttools.
This makes it easier to keep the qmakelib copies in sync.
The code guarded by PROEVALUATOR_CUMULATIVE is not used by qmake itself,
but only by lupdate and Qt Creator. It seems to be sensible to have the
same behavior with regards to feature file evaluation in both
projects. It was originally introduced in qttools for QTBUG-62478.
The change regarding QT_BOOTSTRAPPED is safe, because the 'process'
feature is available and off in the boostrapped case.
Change-Id: I030ca8b093c017040a9ff9f4bb09a7cca4aa8964
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This code, after applying it to linguist, didn't compile.
Change-Id: I25011a44ca059a149f041f8f07848232883140cc
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Don't use evil hacks that make assumptions
about QString internals.
Change-Id: I663602d197f0fcf62886dbfb9a87547097cdab04
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
As a side effect, data() can now return a nullptr. This
has the potential to cause crashes in existig code. To work
around this, return an empty string from QString::data()
and QByteArray::data() for now.
For Qt 6 (and once all our internal issues are fixed), data()
will by default return a nullptr for a null QString, but we'll
offer a #define to enable backwards compatible behavior.
Change-Id: I4f66d97ff1dce3eb99a239f1eab9106fa9b1741a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QChar ctors from non-char-types are going to be deprecated.
Change-Id: I17d7916fb1dac9889ead61daca846b1257d17312
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use the DotMatchesEverythingOption for all places
where we interpret .pro files, to increase compatibility
with QRegExp.
Change-Id: I347d6b17858069f3c9cedcedd04df58358d83f27
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Should improve performance and is going to be required in
the future anyway.
Change-Id: I89d7c50441d2491da1ab0a4d564dcc91f52ade85
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
This is required, so that QHash and QSet can hold more
than 2^32 items on 64 bit platforms.
The actual hashing functions for strings are still 32bit, this will
be changed in a follow-up commit.
Change-Id: I4372125252486075ff3a0b45ecfa818359fe103b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The Qt version was added in 5.14 "for use as eventual replacement for
QString::SplitBehavior." Move another step closer to that goal.
Change-Id: I3f1b836cfb47bba0fdc27f2c3aa7b0576d123dca
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
qmake relies heavily on stable references to nodes stored within the
container. QHash in Qt6 doesn't offer that guarantee, so use a QMap
instead, that supports this.
Change-Id: Ifcf3d67098585ea26f4e02f4570d407a56e33c9c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This can be expensive. We don't expect files to be added to the
directory while qmake is running, and if that happened, the result would
be unpredictable anyway.
Change-Id: I5db93132046c1284130bbe51ce1ecd2a14665206
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ProFunctionDef is move-enabled, meaning its `m_pro` field can
become nullptr. Its usage in the assignment operator and the dtor
must therefore be protected with a check.
Amends 9c63ad562b.
Change-Id: I0c77b07dc83969565480bbb9d9fc80751d4246b1
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Not visible in QMake, because of too old C++ standard used to compile it,
but in the qttools copy. Fix here, as the authorative source, first.
Change-Id: I2552eccfaab2cef0863686dcd888f2a5f25ca29f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QChar currently is convertible from nearly every integral type. This
is bad code hygiene and should be fixed come Qt 6.
The present patch is the result of compile fixes from marking these
constructors explicit.
Amends 60ca2f5f7c.
Change-Id: I06887104d42f8327eb6196afcde5f942a74a6a78
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
This reverts commit 224a60989e.
Turns out that we cannot just untangle the determination of
source root and build root, because this breaks the assumption
that every .qmake.conf results in a separate .qmake.cache in the
build tree. QTBUG-76140 must be fixed differently.
Fixes: QTBUG-76907
Change-Id: I5c0a3719d5e00a0f1cacad51651b47c1f284d22d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This saves us lots of .toQString() and .toQStringList() typing when
qDebug()'ing qmake code.
Change-Id: I037e5e1816f2dcb6a20dec4c275f3d886f155ad5
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Otherwise, it can happen that parsing goes on forever in cumulative
mode.
Task-number: QTCREATORBUG-17656
Change-Id: If69f2265ac7eee0d230bd77a9aa9500e97ebeff6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
QMake searches a .qmake.conf file to determine the source root of the
project, and a .qmake.cache to determine the build root.
If a .qmake.conf exists but no .qmake.cache in the build directory is
found, a build root would be set that is only valid if the build
directory is at the same depth as the source directory.
The invalid build root resulted in the creation of .qmake.cache files
at "interesting" locations (e.g. high up in the directory tree), a
potential cause for even more interesting build failures in the
future.
Fix this by splitting up the loop that determined build and source
root. Both are now determined independently of each other.
Fixes: QTBUG-76140
Change-Id: Ib5c922b87879fcf2f076298a69abcdbc4e8587b3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
IoUtils::isRelativePath() didn't attempt to consider UNC paths, due to
a belief that qmake fails on them so badly that it wasn't worth the
extra code. However, it turns out Qt Creator's copy of this code does
need to take this into account, so start the change off in qmake's
version so as to keep in sync.
Task-number: QTCREATORBUG-21881
Change-Id: I3084b87c1d3ca6508255e94e04ac8db3ceaebb7e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QFile/QFileInfo::readLink() functions are obsolete but were not marked
as deprecated.
Explicit mark them as deprecated so they can be removed with Qt6.
Change-Id: I52424dc5441e1f5b01015713df990bbec5186caa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
The read from a QHash needs to be protected too if other threads are
writing.
sync-up with qtc, no actual effect on qmake itself.
Fixes: QTCREATORBUG-21416
Change-Id: I75e5634e11b10056d6dbb6fdceef482ca2222ca1
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
(cherry picked from qtcreator/5f79b5d2e5e33321cdcd00362f0d6d9442a73ec2)
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Also clean up QTextCodec usage in qmake build and some includes
of qtextcodec.h.
Change-Id: I0475b82690024054add4e85a8724c8ea3adcf62a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
turns out that flushing the ids together with the ProFile cache was an
abysmal idea, as the latter expires after a few seconds after loading
the project, while references to the ProFiles (and thus the underlying
file ids) are kept for as long as the project stays loaded. the early
flush would cause re-use of the file ids, which would wreak all kinds of
havoc when re-loading projects.
but just ref-counting the vfs class is insufficient as well, as then the
ProFile cache (which expires after a timeout) could outlive all VFS
instances and thus refer to ids which were discarded and later re-used.
so we ref-count, and additionally let the cache instance hold a
reference to the vfs class.
this is sync-up with qt creator; no actual effect on qmake itself.
amends 190aa94be.
Change-Id: Idd4478ffc1c2405b3b83df32fba45b1f687f6a18
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
(cherry picked from qtcreator/d03fb350672d311dccc06f0bcb4da744a3c99745)
(cherry picked from qtcreator/1ddfb443b686ef04cc0e28363308ce70d01f0d73)
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
It's 160ish lines and adequately isolated. Still, it *might* be
contributing to compilers being slow (unlikely though that seems) so
seemed worth tidying up anyway.
Task-number: QTQAINFRA-2117
Change-Id: I9e55e677552c273fdf3480ccefc229fd6fd2b66a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
