Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
According to the old explanation inside makefileParsingFinished()
the solution of using sender() can't work reliably in this
case. In scenarion where the old, deleted m_makefileParserThread
had the same address as newly allocated one we might not detect
correctly posted finished() signal of the deleted object.
According to QObject::sender() documentation:
"The pointer returned by this function becomes invalid if the
sender is destroyed", so we can't rely on its value.
Instead, add a new done() signal to the MakefileParserThread,
which is being emitted from MakefileParserThread thread (i.e. from
the thread where MakefileParserThread object lives in). In this way
the finished() signal is still posted to the caller's thread,
but this time if the MakefileParserThread object is already
deleted, the finished() signal will be gone together with the
MakefileParserThread object itself, so we also won't receive done()
signal anymore.
Simplify the internals by using std::unique_ptr.
Change-Id: I43be209ecb71539ddefd72e50e9d60bfb43c49cb
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The old code model expected the macros as C++ formatted text
("#define Foo 42) but newer targets like the Clang codemodel expect key
value arguments like "-DFoo=42". So instead of parsing the text again and
again we use an abstract data description.
Task-number: QTCREATORBUG-17915
Change-Id: I0179fd13c48a581e91ee79bba9d42d501c26f19f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Use pragma once
* Make sure overrides are everywhere
* Clean up code here and there
* Remove useless code from initializer lists
Change-Id: I9c285a803ea36cb32d14b3335757fd4b57f27d02
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Fixing an lupdate warning about cyclic dependencies of
autotoolsbuildsettingswidget.h.
Change-Id: I0e1c721df2c5f70ae9de38dd9bc5a34b63622ba7
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
