It is not possible to manually edit the `config.opt` and do a redo, and
`configure/` uses the `config.opt` in this case.
Task-number: QTBUG-108287
Change-Id: I3d87b13a900b97fb50e49a4f155bec964ecb5d1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In addition to the fix, I've removed some legacy codes in the
`configure` file and delegated most of the work to
the `QtWriteArgsFile.cmake` which was being used by `configure.bat`. I
am not sure how this was supposed to work before since it was not really
working, but now, `config.opt` lives in the build directory, together
with `config.opt.in` (a template file), and the `config.redo` (and
`config.redo.in`) which holds the full redo command. The template files
are being used to preserve the quoted variables and to help
QtWriteArgFiles process the opt files more consistency.
Also fixed an issue on Unix, where ./configure was failing to run if
its path contained spaces, e.g., `Qt Src/qt5/configure`.
Fixes: QTBUG-108287
Change-Id: I9843b690a1fd3177a93e55e08a3484a4c85ba2e8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the case of re-doing, `configure` and `configure.bat` pass an extra
parameter to the `QtProcessConfigureArgs.cmake`. As a result, CMake
removes CMakeCache.txt and CMakeFiles/ before the reconfiguration. If
the user is using CMake 3.24 or newer, this is achieved by passing
the `--fresh` option to CMake call. In older CMake(s), CMakeCache.txt
and CMakeFiles/ found in CMAKE_BINARY_DIR will be removed using a
file(REMOVE_RECURSIVE call.
[ChangeLog] The -redo option now additionally removes existing
CMakeCache.txt file, and CMakeFiles/ directory, and recreates them from
scratch.
Task-number: QTBUG-108287
Change-Id: I11a5c8f9df1247d11eb7097552e6764463583346
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If there are no arguments, echo will print its status, and config.opt.in
will contain
ECHO
is
off.
Fix this by using "echo." idiom.
This amends 57ad532e75
Pick-to: 6.2 6.3
Change-Id: I1697e59f23cd28256a4a6ce357eae70e36c49d5a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If the original configure arguments contained equal sign(s) like in
configure ... -- -DQT_BUILD_SUBMODULES=qtbase;...
The following error message was printed:
=qtbase was unexpected at this time.
The reason is that the conditional
if "%rargs%" == ""
would expand to something like
if ""-DQT_BUILD_SUBMODULES=qtsvg"" == ""
which is invalid, because the equal sign is used outside of a string
literal.
Use delayed expansion in the conditional to fix this.
Pick-to: 6.2 6.3
Change-Id: I8c40d799db2c5aae8cba190ed31804c71a605935
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This is a preparation for adding the -help argument to
qt-configure-module.bat.
Consider the call
qt-configure-module.bat path/to/qt-module -help
Internally, we called
cmake ... -P .../QtWriteArgsFile.cmake path/to/qt-module -help
which was supposed to separate the arguments and write them into
config.opt.
However, passing arbitrary arguments after "-P script.cmake" only worked
by accident and is not supported. As soon as arguments are passed that
are valid CMake arguments, like -help or -G, the CMake call would fail.
Now, we let configure.bat and qt-configure-module.bat write the
arguments as is into config.opt.in and let QtWriteArgsFile.cmake read
this file, separate the arguments and write config.opt.
Pick-to: 6.2
Task-number: QTBUG-95943
Change-Id: I80f298a2aaf55b0f79fed86320a055eb2d2b6faa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt is built with CMake since 6.0 and the QMake build system was removed
in 6.1. It's time to remove the -cmake and -qmake configure arguments
for Qt 6.2.
Fixes: QTBUG-88286
Change-Id: Ie726ec364ded025f8d93bd69b469561a6ae40aa9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This leaves a very simple script that delegates the heavy configure work
to a CMake script.
This also removes the Makefile templates that were used for
bootstrapping qmake.
Task-number: QTBUG-88742
Change-Id: Iab9c477e0bb611d680bda2cf8aaa7ad88356a8d1
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Print an error message when configure is passed the -qmake option.
The only supported way to build Qt now is with CMake.
This means the CMakeLists.txt files are the source of truth now, and
pro2cmake will not have to be used anymore.
The .pro files can be removed at a later time.
The same is true for configure.cmake files. They are the authoritative
source, and the configure.json files will be removed at a later time.
Task-number: QTBUG-88741
Change-Id: Ia9de4c1411978b40b13e9b982977e7818164c984
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We must write config.opt in the same directory we're reading it from.
We must not write the -top-level argument to config.opt.
This amends commit 2a29426e39.
Change-Id: I96da9094579fec29c290411677d6b538878399f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
People that insist on qmake builds of Qt can configure with -qmake
Task-number: QTBUG-87049
Change-Id: I5729b654d4c8b9c6b526234ba5563aff8fd750e1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option configures Qt with the qmake-based build system.
Currently, this is the default, so this option is a no-op until the
default switches to CMake.
Task-number: QTBUG-87049
Change-Id: I56f3080a4f1423788ffb743287a7b2e67a8e2cc4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When re-doing in a top-level build, we did not read the config.opt file
from the top-level directory.
Also, the config.opt file should not contain the -top-level argument.
This is an internal option, and on Windows, it was already missing. The
information whether we're doing a top-level build is now passed in the
CMake variable TOP_LEVEL.
Change-Id: Iaecd7306a4b6d9ad494684c201cf12f8e74d684b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The working directory for CMake must be the top-level build dir, not the
qtbase one.
Change-Id: I1090aca8bf2617719e724f96b1fa356eb9fabb46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The configure scripts need to translate configure options to CMake
arguments. It is not sensible to implement this translation twice, in
sh and Windows batch language, so we're doing this once, in CMake
language.
The configure scripts write their options into config.opt and call a
CMake script that reads config.opt, does the translation to CMake
arguments and calls CMake to generate the build system.
While we're at it, implement some more translations than the sh
configure provided, like -extprefix, -top-level and -skip.
Fixes: QTBUG-85349
Fixes: QTBUG-85350
Task-number: QTBUG-85373
Change-Id: Ida5d8b2a3c178b9349d41ec76d190c69a9456e74
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is a remake of 8e4c8be0b9 that was
undone by mistake in 8f49da6c18.
Change-Id: I9596b860dea90b042baa8b2b95b1e3b050e9b835
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
these variables have no legitimate use when building qt itself, but have
great potential to wreak havoc.
Task-number: QTBUG-60016
Change-Id: I161837463443af82d48145e75952fa529212fe75
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
for some inexplicable reason, configure.bat went into an endless loop
on win 8.1+ while attempting to parse the command line; this is clearly
a bug in cmd, so work around it.
amends 7af6e9bb.
Task-number: QTBUG-58019
Change-Id: I698a2a51891a4e7af75836c075888f70df865409
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
this is rather hacky. a proper solution would auto-generate help from
the command line argument definitions, at the cost of needing to
bootstrap qmake first.
Change-Id: Iada6e25d5b31d7db0595309887f2d13295bbc1e3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
now that the bat file is responsible for displaying the help in addition
to bootstrapping configure, the exe file should not shadow it any more.
amends c027cffbe.
Change-Id: I5c8a52f59ff455575e646fae55cd214db98a3736
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
now that configure.bat takes care of printing the help screen itself,
there is no compelling reason to ship configure.exe in the source
packages any more. consequently, always bootstrap it.
Change-Id: I5bf0946549e3c426c1a4a94b1c22f6c0f4b4993c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
specifically, make configure.bat dump the text file (which got some
windows-specific adjustments).
incidentally, this change removes the need for including a pre-built
configure.exe into our source packages.
Change-Id: Ib3515c113f3602767554fe1493df226551a7bf10
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Sometimes clang-cl.exe is on PATH and would get picked up by the
build. That is often by mistake, but it will inreasingly happen
as clang-cl becomes more popular. Unfortunately, configure.bat is
too early to detect which MSVC version it's set to compile
against, so the -fms-compatibility-version option will often be
wrong. One such case is when trying to build for MSVC
2013. Microsoft headers for VS2013 are unsuitable for our use in
Qt with clang-cl.
Instead, use cl.exe. It's a much better-known quantity and is
always on PATH if trying to build with clang-cl, as the latter
needs the former to fall back to if necessary.
This does not affect the build of Qt libraries and tools.
Task-number: QTBUG-51534
Change-Id: I149e0540c00745fe8119fffd146287662436c4b9
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
I changed qmake with commit f5eeadb9, but that change was apparently
incomplete.
Change-Id: Ib57b52598e2f452985e9fffd1458b02579f33c5d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
This adds the functionality to build Qt with clang under Windows against
the Microsoft Visual Studio 2015 runtime.
In order to replicate this, a Clang 3.8 build with Visual Studio 2015
Update 1 is needed.
Adds compiler detection to Qt to distinguish correctly the clang compiler
and Windows with Visual Studio.
Clang has some built-in numeric functions, there is no need to use the
Microsoft versions, which also conflict here.
Task-number: QTBUG-50804
Change-Id: Ia4b267a298310ac7d73edf473b12792991249d8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
I wrote a script to help find the files, but I reviewed the
contributions manually to be sure I wasn't claiming copyright for search
& replace, adding Q_DECL_NOTHROW or adding "We mean it" headers.
Change-Id: I7a9e11d7b64a4cc78e24ffff142b506368fc8842
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
It's easier to parse than qglobal.h. The objective is actually to have
macros with parts of the version number, so the major or minor numbers
could be used in other preprocessor macros.
Change-Id: I42e7ef1a481840699a8dffff1404eda1dd5c308d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The Intel compiler's compilervars.bat also puts the MSVC compiler in
PATH, so cl.exe was always being found first.
Change-Id: I72e524da10fb0e221c4530a3e5c1a4a347c3f878
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
spaces in the source dir are not supported for now, as that requires
some more profound refactoring of the bootstrap makefiles.
Change-Id: Ie0c07a1558b8326f642f2ea144bc1cd85ee761af
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
instead, rename it to syncqt.pl and rely on qtPrepareTool()'s new
ability to correctly invoke it as a perl script even under windows.
the wrappers themselves have been trivial at this point, so there is no
added value in keeping them, either.
Change-Id: I77cf65edbcfaa48ed1900defe940d4eb4b82d5b9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
the build steps are now fast enough to make no-op rebuilds no problem.
Change-Id: I1018735bf50f3e7a66e22637237f26f98a3baf1d
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
