People tend to "turn off debug and release builds" by just not building
one of the variants. For example, Qt's own rcc is built in release only,
however it is configured for debug_and_release with the same TARGET for
both.
Let qmake complain about conflicting TARGETs only we're about to build
all of those conflicting targets, i.e. if build_all is set.
Change-Id: I0448bf5cb421e2d801d3cc30e0d80353fba0d999
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
...with a failing test case for QTBUG-77299.
Task-number: QTBUG-77299
Change-Id: I42c4fc4bb96f8660f8ff9bea97e6096ca6cec972
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Windows resource files support a subset of C preprocessor directives.
Among others they can have #include directives.
Use QMake's own scanner to retrieve the files that are included by a
Windows resource file and add them to its dependencies.
For the test case the TestCompiler class had to be extended:
runCommand is now public, and commandOutput is less peculiar.
Fixes: QTBUG-3859
Change-Id: I138703352c37c98297c0574a9a440510c1c494b8
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If a project has DESTDIR and TARGET set to fixed values, then the
target paths conflict when doing debug_and_release builds.
With this change we're detecting this situation and yield a warning.
Fixes: QTBUG-2736
Change-Id: Ib163db3463322792ab9fa5b997285ac9fc9819ab
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Instead, use (void)x; directly.
The current use of Q_UNUSED(x); generates warnings for an
empty statement the expansion of Q_UNUSED contains a semicolon
already.
Emitting Q_UNUSED(x) without the extra semicolon would be
an option, too, but as the future of Q_UNUSED's embedded
semicolon seems unclear right now, avoid its use altogether.
The change affects only generated code that's barely ever
read by a human, so the overall utility of "improved readability"
of Q_UNUSED in that place is questionable anyway.
Change-Id: I332527ed7c202f779bd82290517837e3ecf09a08
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Windows has a problem relating to cross-DLL variable relocations: they
are not supported. Since QMetaObject's link to the parent class is done
via a pointer, every QMetaObject in a DLL or in the EXE that derives
from a class from another DLL (such as QObject) will be dynamically
initialized.
This commit changes the meta object pointers in QMetaObject::d from raw
pointers to a wrapper class SuperData, which is almost entirely source-
compatible with the pointer itself. On all systems except for Windows
with Qt 6, it's binary compatible with the current implementation.
But for Windows with Qt 6, this commit will store both the raw pointer
and a pointer to a function that returns the QMetaObject, with one of
them non-null only. For all meta objects constructed by moc, we store
the function pointer, which allows the staticMetaObject to be statically
intialized. For dynamic meta objects (QMetaObjectBuilder, QtDBus, QtQml,
ActiveQt), we'll store the actual raw pointer.
[ChangeLog][QtCore][QMetaObject] Some internal members of the
QMetaObject class have changed types. Those members are not public API
and thus should not cause source incompatibilities.
The macro QT_NO_DATA_RELOCATION existed in Qt 4 but was called
Q_NO_DATA_RELOCATION and only applied to Symbian. It was removed in
commit 24a72c4efa ("qglobal: Remove
symbian specific features").
Task-number: QTBUG-38876
Fixes: QTBUG-69963
Change-Id: Id92f4a61915b49ddaee6fffd14ae1cf615525e92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
- Replaced the usages of deprecated APIs of corelib by corresponding
alternatives in the library code and documentation.
- Modified the tests to make them build when deprecated APIs disabled:
* Made the the parts of the tests testing the deprecated APIs to
be compiled conditionally, only when the corresponding methods are
enabled.
* If the test-case tests only the deprecated API, but not the
corresponding replacement, added tests for the replacement.
Task-number: QTBUG-76491
Task-number: QTBUG-76539
Task-number: QTBUG-76541
Change-Id: I62ed4a5b530a965ec3f6502c6480808f938921aa
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The -d option makes rcc output a dependency file with the specified
file name.
The resulting dependency file is useful for make or ninja based build
systems.
[ChangeLog][Tools][rcc] Added -d option to generate a dependency file.
Fixes: QTBUG-45460
Change-Id: I495ade50f8d9865d4c00dce9373b2b6d1a6c8f2f
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
A recurring problem with the Q_NAMESPACE macro is that it declares
an object (staticMetaObject) in the surrounding namespace. That
object lacks any export/import qualification to make it usable
with shared libraries.
Introduce therefore another macro to work around this issue, allowing
the user to prefix the object with an exporting macro, f.i. like this:
Q_NAMESPACE_EXPORT(Q_CORE_EXPORT)
The old macro can simply then be rewritten in terms of this new one,
supplying an empty export macro.
Note that NOT passing an argument to a macro expecting one is well
defined behavior in C99 -- the macro will expand an empty token.
Of course, MSVC doesn't like this and emits warnings. As a
workaround, use a variadic macro.
[ChangeLog][QtCore] Added the new Q_NAMESPACE_EXPORT macro. It
can be used just like Q_NAMESPACE to add meta-object information
to a namespace; however it also supports exporting of such
information from shared libraries.
[ChangeLog][Potentially Source-Incompatible Changes] Prefixing
Q_NAMESPACE with an export macro may no longer work. Use the new
Q_NAMESPACE_EXPORT macro for that use case.
Fixes: QTBUG-68014
Change-Id: Ib044a555ace1f77ae8e0244d824ec473550f3d8e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
For applications that set VERSION the installation targets of pdb
files were wrong in qmake's nmake Makefile generator.
Replace code that tries to reconstruct that target's versioned
extension with TARGET_EXT which already contains the fully resolved
target extension.
Fixes: QTBUG-74265
Change-Id: I9553a5f70170e077a59c866079ae51647ae80bef
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Copy the test data into a temporary directory and do all the work there
without tainting the source directory. More importantly, do not pull in
any settings from the Qt build to test what actual users will encounter.
Change-Id: I793b86bfadb7597efb47c8f2d3fc863384c78a79
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Change b86d0b6215 rearranged the
sequence of function calls when generating code adding QTabWidget
and QToolBox pages, not taking into account that the iconCall()
has a side effect (writing out icon definition) Revert that part
and add a comment.
Fixes: QTBUG-72980
Task-number: PYSIDE-797
Change-Id: Ie8fbaa36f21cd4408fb1f491195da5c260708e6c
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Also blacklist tst_QRawFont::unsupportedWritingSystem() and
tst_QGlyphRun::mixedScripts() on windows for now.
Conflicts:
qmake/generators/makefile.cpp
src/corelib/itemmodels/qstringlistmodel.cpp
src/platformsupport/fontdatabases/windows/qwindowsfontengine_p.h
tests/auto/corelib/itemmodels/qstringlistmodel/tst_qstringlistmodel.cpp
tests/auto/gui/text/qglyphrun/BLACKLIST
tests/auto/gui/text/qrawfont/BLACKLIST
Task-number: QTBUG-72836
Change-Id: I10fea1493f0ae1a5708e1e48d0a4d7d6b76258b9
C++11 added the new enum class key as well as enum struct. While the
former is likely the most known and used, the later can be used in the
same contexts and with the same effects.
Currently moc doesn't parse enum struct while it does for enum class.
This patch fixes this.
[ChangeLog][moc] moc now parses enum struct the same way as enum class
therefore that keyword can be used with the Q_ENUM macro as well as
Q_FLAG and Q_DECLARE_FLAGS.
Change-Id: Iaac3814ad63a15ee4d91b281d451e786b510449c
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add a lookup for the affected enum values and use the names instead.
Task-number: PYSIDE-797
Change-Id: I6be166409000aff83d9465c9a3b2f37b44c5c085
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
This solution is composed of two features:
1) C++ code generated by RCC uses two symbols exported from QtCore that
are only present if the feature was compiled in. If the feature was not
compiled in, this will cause a linker error either at build time or at
load time (if they were functions, the error could be at runtime).
2) Binary files generated by RCC have a new header field containing
flags. We're currently using two flags, one for Zlib and one for
Zstandard.
This means we now have binary RCC format version 3.
Change-Id: I42a48bd64ccc41aebf84fffd156545fb6a4f72d9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- Fix some clang nags (QFileInfo::exists(), raw string literals).
- Update the version numbers in the baseline to be 5.12 consistently
to make future modifications easier.
- Introduce another environment variable to redirect the diff
output to stderr. This can be used to generate a diff for applying
when making larger changes to uic.
Task-number: PYSIDE-797
Change-Id: I3f6716f0fe8e5939f6bef3965d90b2bb2c37f4c4
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Replace the generation of #ifdef's for the macros by QT_CONFIG
checks. Implement it using streamable classes to make it easier
to switch the output language later.
Task-number: PYSIDE-797
Change-Id: I28b5ed3ec80cd525a3df0cd54d9be4f09149cde4
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Make the code consistent with the DomProperty::write() method.
Task-number: QTBUG-70613
Change-Id: I622b4a019a4473823584de97304f8324f2cf0c6b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Moc shouldn't artificially introduce calls to possibly overloaded
operator&. It can cause odd side effects in a user code.
Change-Id: Iaa1b491fe6a1a5ebd4dfa1172359dc792cc7604f
Fixes: QTBUG-68191
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- three more tests cases on expected .qrc generation
- a new test comparing data read via resource with
the same data directly read from the original file
Change-Id: Ic34e68c9fc3fa110110161b57d4129ae44419020
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Adds an enumName to QMetaEnum to carry the name of the enum since for
flags that doesn't match the name of the Qt type, but is needed if the
flag is scoped.
Change-Id: I1c0f77eb9e40e6fd1eb6a59bea77caf0f33fcf43
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Keep the original class name around for a little longer so we can
generate the correct scoped enum in the moc output.
Task-number: QTBUG-47652
Change-Id: Ib5934316fa786cc475335b03c86b8ec2dc239055
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This reverts the following commits:
d12d2949d126c3bec09b49b08f96e8
We can't easily predict all code paths for QDesigner
with such a microoptimization. We also don't want
to generate three different string constructions
depending on some sophisticated heuristics.
[ChangeLog][uic] The -no-stringliteral option is now deprecated and
UIC will not generate QStringLiteral anymore.
Task-number: QTBUG-65251
Task-number: QTBUG-51602
Change-Id: I34a5a1934a8df19c5c84ac2ba8e5168ce5665037
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
at the time this patch was conceived, it was meant as an exercise in
getting rid of usages of ProString::toQString(m_tmp). however, this was
meanwhile superseded by use of toQStringView().
but the change itself should have been done a long time ago already, and
there is no harm in going through with it.
on the way, this also unifies and fixes some of the error messages.
Change-Id: I337aff994c508df783df4794c3fa0762d83a691b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
sync-up with qt-creator; no effect on qmake.
comment on cherry-pick: this is actually a lot more than a cherry-pick,
because the dual VFS needs to deal with the file ids which were
concurrently introduced on the qmake side.
Change-Id: I2c1eb16c97526fa275a1c6a2eae9266d385859ac
(cherry picked from qtcreator/424639ecac9d2e404d2bfaff7f46b45ed98664b8)
(cherry picked from qtcreator/a8010b0fff47d903d4a1f80e3adb1a2ef41beb33)
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
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>
We can use the QT_LIB_FOO #defines instead of our own WITH_FOO ones to
determine if a library is available. Also, it doesn't currently make
sense to refer to libraries which are not part of qtbase here. We might
add that in the future, but QtScript (being deprecated) is probably not
the first one we should add.
Change-Id: I7f2397ca5499ba6003088478161182e960e815fb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This follows on from a232251992 which
covered a similar instance of this. As with that change, we should not
abort the compilation, just ignore it.
Task-number: QTBUG-63772
Change-Id: Ide958080a90f43ed19edd8a320e7d45de1c96821
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>