when the QFile object is already constructed, querying whether the file
exists is actually cheap, so do it right away instead of later on
demand. that makes the calling code a bit cleaner.
fwiw, that we need to explicitly query the file's existence at all is a
result of QFile's completely useless error "codes" (which merely say
which function failed, as if the caller would not know).
Change-Id: Ifec39d05b1713d8128046f679287e510f10e45dc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
(cherry picked from qtcreator/5ba32e3484ead2e35cc7732dcd59a97e7459dbfd)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
just a sync-up from lupdate; no effect on qmake itself.
alternative source: qt-creator/7e86b98836342035684cc1c1aa49292224faed07.
Change-Id: I5e10b44637d527799f55c578a99076eb4750f131
(cherry picked from qttools/8e7e60dbdea04c943bc6d50290db12d3fefd39f2)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Thanks to QTBUG-61373, this qmake function was called with
/usr/local/5.10.1 as baseDir, which isn't absolute, leading to an
assertion failure. We could raise the error within qmake but it
proved easier to simply resolve any non-absolute baseDir using PWD,
before trying to use it as an absolute path.
Did the same for $$absolute_path(). Documented both. Adjusted the
assert that caught this to report any non-absolute path that upsets
it. Added simple tests, fixed an existing test.
Task-number: QTBUG-66156
Change-Id: Icfef2e2f5b236e071177c9beffa38d71bf404292
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This ensures that the generated XCode project can correctly find any
files that are referenced via a path containing "..".
Task-number: QTBUG-35131
Change-Id: I049bc2279b4c515a82acd61142d25b8c240e8f6e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Removed duplicate "for the".
Function list was sorted except for sprintf; so sorted it. Also, minor
grammatical improvement.
Task-number: QTBUG-64362
Task-number: QTBUG-64363
Change-Id: Ia47c5195011a0e578e916897b3a5ddb1d78170ad
Reviewed-by: Frederik Schwarzer <schwarzerf@gmail.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This is in preparation to adding CBOR support. We don't need yet another
dir for CBOR and placing it in src/corelib/json is just wrong.
Change-Id: I9741f017961b410c910dfffd14ffb9d870340fa6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Make it clearer what the variable actually does by mentioning
that it makes its headers available for inclusion and causes
it to be linked to the binary.
Change-Id: I72821d4bceea7a92e91175ba6c5acc4c3377d7b7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QFileInfo.isRelative() deems any path starting with a slash to be
absolute; on MS-Win, such paths need a drive specifier (unless they're
UNC), so use IoUtils's more robust test for absolute paths.
Change-Id: I7d0872a87833cbf1cc1a6ef107941adc4c529624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Removed the '!' from two comments because the functions being
documented are static functions declared and defined in the
.cpp file. They are not public.
Change-Id: Ie3b2c32c64102634b6b2a4c438da191536a426d6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
For Q_OS_WIN, a path is only truly absolute if it includes a drive
letter; merely starting with a slash is not enough. (We can't support
UNC paths, so don't even try: qmake runs various commands in the
source directory using CMD.exe, which doesn't support UNC as PWD.)
This requires, when resolving a path relative to a root, transcribing
the root's drive to such not-quite-absolute paths.
Changed QMakeGlobals, $$absolute_path() and $$relative_path() to now
use IoUtils::resolvePath() rather than delegating to QDir's absolute
path method, since that doesn't correctly recognize the need for a
drive letter (and qmake did run into problems with some paths, from
splitPathList and a failing test, as a result).
Moved existing ioUtils tests for handling of relative / absolute paths
out into separate functions and expanded significantly. Fixed some
existing tests to use an absolute path where one is needed; added two
tests involving driveless (but rooted) paths; and fixed the test init
to set a value for QT_HOST_DATA/src property (the lack of which lead
to an assertion failure with this fix).
Task-number: QTBUG-50839
Change-Id: I2bfc13c1bfbe1ae09997274622ea55cb3de31b43
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
These are no longer part of Qt 5 and produce documentation warnings.
Change-Id: I82242b7b03d7ece1b82e2ff75dc6673f471e2df2
Reviewed-by: Martin Smith <martin.smith@qt.io>
MSVC requires that the C PCH file is compiled (as an object) and linked if
any C file is found, and the same for C++.
Most qmake projects are C++.
If a C++ project has a precompiled header, it is typically of C++ type, and
cannot be compiled as C (for example, it contains or includes classes).
Since there is no easy way to conditionally build the C PCH file only if C
files are found in the project (as done for g++), we need a setting that is
disabled by default.
This amends 30331afda1.
[ChangeLog][Tools][qmake] Introduced precompile_header_c CONFIG option for
MSVC to enable precompiled header for C sources.
Task-number: QTBUG-65103
Change-Id: Id9688a35ee7d9b5e4f5a846b81986cb674bc5f4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This ensures that the same set of variables can be successfully replaced
in both the Makefile and Xcode generators. It also switches the default
templates to use the Xcode-style ${var} syntax instead of the @var@
syntax for better Info.plist compatibility across generators.
Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Since Xcode 6.3, this must be set to NO because stripping on copy is no
longer fully supported due to the potential of input binaries being code
signed. In this case Xcode will simply ignore the strip step and issue
a warning since stripping would invalidate the code signature. This
change silences that annoying warning for release builds. Also, the
setting assignment is moved from being hardcoded in the generator, to
a QMAKE_MAC_XCODE_SETTINGS value.
Change-Id: If25511edddc12b7b0407e2992d80884b7d6437dc
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This problem does not affect the Xcode generator.
Task-number: QTBUG-65477
Change-Id: I6194edc5b679edad9ae1a25e35b71e5df9bd4c95
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This was missed in 8bebded9.
Task-number: QTBUG-63637
Change-Id: I6be472430a9aa8f533def4fd6c14c8dbfe8b6f70
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The update adds the moduleheader variable to the qdocconf
file for qttestlib.qdocconf and qmake.qdocconf. The problem with
qmake is that it doesn't have a module header file, but it does
have qmake_pch.h, which is used here. This update also corrects
several \fn commands in the qttestlib docs.
Change-Id: I2202b9db96390bac1ee491ca8a99ca9010057ce3
Reviewed-by: Martin Smith <martin.smith@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
In Xcode, the default value for GCC_GENERATE_DEBUGGING_SYMBOLS is YES,
which causes Xcode to emit debug symbol bundles (.dSYM) on macOS and iOS
*if* DEBUG_INFORMATION_FORMAT is also set to dwarf-with-dsym. Since that
setting is already set to an appropriate value with debug vs release
builds, the default Xcode value for GCC_GENERATE_DEBUGGING_SYMBOLS is
already correct and in effect the only thing qmake was doing was always
setting GCC_GENERATE_DEBUGGING_SYMBOLS to a wrong value for release
builds - it should be YES in all cases, to allow the .dSYM bundles to
be generated in release mode, which is in fact the only case where
they're really needed in the first place.
Task-number: QTBUG-41246
Task-number: QTBUG-50896
Change-Id: I07639a3c4ff9f62d591cde3ad66748767d475e3b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This helps alleviate a performance issues where by building iOS based
projects takes a significantly longer amount of time than it should.
Task-number: QTBUG-59136
Change-Id: I77ae12f507725ceb11106b484d73bb7d46e0845c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This is C++, not qmake code. Amends 5fa6438633.
Change-Id: Ie5b88c3a06dbe089948488ea3b4b297a08164113
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
SYSTEM is used for system() calls, while SHELL is used in the target
Makefiles.
Task-number: QTBUG-62985
Change-Id: Ia75d3939c59c98699359421166433e8b4a6ee35e
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QMAKESPEC is added in makefile generator,
it is not in INCLUDEPATH.
Change-Id: I2451b3c7b30bc237157e68e5ce9de67f55e784b2
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
When the source file is read-only then it would copy the file with that
attribute set when it is installed. However this will cause a problem
if it is installed a second time. Therefore the read-only attribute
needs to be manually reset before installing and again before touching
the file. Once the process is done then it is set back to be read-only
to preserve the state of the original.
Change-Id: I1c01f418ef3c9bd434acd2c2b8ee695544d7bb35
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Conflicts:
examples/examples.pro
qmake/library/qmakebuiltins.cpp
src/corelib/global/qglobal.cpp
Re-apply b525ec2 to qrandom.cpp(code movement in 030782e)
src/corelib/global/qnamespace.qdoc
src/corelib/global/qrandom.cpp
src/gui/kernel/qwindow.cpp
Re-apply a3d59c7 to QWindowPrivate::setVisible() (code movement in d7a9e08)
src/network/ssl/qsslkey_openssl.cpp
src/plugins/platforms/android/androidjniinput.cpp
src/plugins/platforms/xcb/qxcbconnection.cpp
src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
src/widgets/widgets/qmenu.cpp
tests/auto/widgets/kernel/qwidget_window/tst_qwidget_window.cpp
Change-Id: If7ab427804408877a93cbe02079fca58e568bfd3
It was already done correctly in the GCC generators, but lacked in MSVC.
Task-number: QTBUG-11117
Change-Id: I5e6c2e4802dbe33c0f15c46a227a08c3f0cc5707
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the replacement value may well constitute the whole output string - this
is in fact common, given this rather typical usage pattern:
BAR = $$replace(FOO, -flag, -otherflag)
this must be considered when constructing the return value.
compare 3c8134958c.
as of now, this is irrelevant, as QString::replace(QRegExp, QString) will
always memcpy the replacement into a detached copy of the target, but one
never knows.
Change-Id: Ia1f271f45023746040fc28ce6d88a6609e05e5c2
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
technically, we should not rely on the i/o classes not storing the
strings beyond the instantiated object's life time.
Change-Id: I0990769b3cf86860184869036c096c531160e9be
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
property values are de-facto guaranteed to be backed by full QStrings,
so there is nothing to be gained from using the raw data optimization,
while doing so risks raw data leaks.
Change-Id: I3d43da9aaadd4d5811c4b1a9d7ac734049da423c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
it's not clear why detaching would be necessary; there is no danger of a
raw data leak here.
concatenating a QStringRef with a non-empty QLatin1String (the only
expected use of this overload) will yield a detached QString anyway, so
this makes little difference in practice.
amends f137957e08.
Change-Id: I521c0e89a8b0c1ae62b1450e81b0ae91a931bcfa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
no m_tmp is involved any more in this code path; it uses QStringRef.
amends 11d957d043.
Change-Id: Ib272d61edfb150a549c5e6a9a60d53502702e802
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the m_tmp array is a member, so the index toggle for accessing it also
needs to be one - otherwise, odd iteration counts will defeat the
mechanism.
Change-Id: If7a800ed5a4b4168625daf1ebbd5d2d164569d8e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... in $$basename(), $$dirname(), and contains(). the latter case is
marginal, as it only applies to mutuals which are regexes, which i don't
remember ever seeing used.
QRegExp saves a copy of the matched string, so it's necessary to
alternate between two temporaries to avoid detaching. we already
did that in most places.
Change-Id: I97b8294585c17c76d1756f83971f42cb88353af0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
in most cases, the main advantage is not using toQString(m_tmp), which
reduces the possibility of raw data leaks. in cases where we used
toQString() without temporary, this is a slight optimization.
Change-Id: Ib343acffd383aa2c4fefab75fb52762fb534dfc6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When a ObjC++ QObject subclass is listed in the regular HEADERS, qmake
creates a .cpp file. The moc file will then fail to compile, as it
requries ObjC++ headers. Using Q_FORWARD_DECLARE_OBJC_CLASS() can be
used to let the class be parsed by The compiler, but link will still
fail, as the generated methods (e.g. signals) must be built with ObjC++
compiler, in case they have ObjC parameters:
Q_FORWARD_DECLARE_OBJC_CLASS(NSString);
class MyClass: public QObject {
Q_OBJECT
signals:
void objcSignal(NSString * myObj);
};
The canonical workaround for that is including the .cpp file into the
corresponding .mm file. This also offers a compilation speed advantage,
but is somewhat counter-intuitive.
Therefore, we introduce a separate variable which instructs moc to create
.mm files directly.
Task-number: QTBUG-1581
Change-Id: Ia98af58006efd168ea37f3a63c396979e7e81baa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
A macro name ending in R might expand to a string; if this precedes a
string constant, we're juxtaposing the strings. My first parser for
raw strings would mistake it for a raw string instead, ignoring the
part of the identifier before R. Re-worked the exploration of what
came before the string to catch these cases, too.
The backwards parsing would also allow any messy jumble of [RLUu8]* as
prefix for the string; but in fact R must (if present) be last in the
prefix and *it* can have at most one prefix, [LUu] or u8. Anything
else is an identifier that happens to precede the string. Reworked
the parsing to allow only one prefix and not treat R specially unless
it's immediately (modulo BSNL) before the string's open-quotes.
Add link to the cppreference page about string literals, on which the
grammar now parsed is based.
Added a test for the issue this addresses.
Verified that this fails on 5.6, dev and 5.9 without the fix.
Expanded the existing test to cover R-with-prefix cases.
Task-number: QTBUG-55633
Change-Id: I541486c2ec909cfb42050907c84bee83ead4a2f4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The $${TARGET}_manifest.bak file was not removed on "nmake clean".
Task-number: QTBUG-59827
Change-Id: Ia5b636f4917f3e7a2df8d753824b72e63d278005
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QMAKE_LINK_OBJECT_MAX is actually a property of the host, not the
target.
this works around binutil's inability to use thin LTO objects in
conjunction with an MRI script
(https://sourceware.org/bugzilla/show_bug.cgi?id=21702).
Task-number: QTBUG-61335
Change-Id: I90a1334b9c905c433b35546e8f3f3b5089d2c65b
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
