| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Task-number: QTBUG-105718
Change-Id: I2ad190e5536cdbdc8d2656e61892545d66911a02
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I118bd63694cfe2c9a413af4a38828a31727f8e86
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous gn-cmake integration was driven towards having the
complete cmake build tree which included gn build artifacts.
These were marked as IMPORTED in cmake build files, this way
cmake "knew" all object files and static libs coming from gn.
To achieve that we needed to run the cmake configure twice.
First to feed gn with the build information from cmake and
then the second run to import all the build information to
cmake based on gn run.
As a side effect of this the first run cmake was creating incomplete
targets, so we could use generator expressions to gather all the data
needed for gn run. The second run of cmake was able to create fully
initialized targets. We used 'external project' to run cmake the second
time.
This approach worked well when doing "module" builds and having two
targets, one in the main project and one in external was not an issue.
Moreover, this approach could be integrated nicely since CI does only
"module" builds.
Unfortunately "top level" builds are implemented to import all qt
targets into one build tree. This created issue for qtwebengine since
fully initialized targets were 'hidden' by 'external project' and
including half baked (dummy) targets from the main project resulted
in bunch of issues related to the dependency tracking and build race
conditions. Also using 'external project' complicated installation
rules and in the end installation worked differently than in other
modules.
With current approach we use response files, so we hide all build
artifacts coming from gn and feed cmake with those response files.
This way we run the cmake configure once and we create all the targets
once. Using rsp files hacks linker options in cmake, so this approach
is sub-optimal, however allows to have working "top level" builds.
It is worth mentioning here that the final module linking has to take
place with cmake's part of build since doing one static lib in gn is
not possible due to the toolchain limitation (msvc is not able to
process static libs over 4Gb and has no support for thin archives,
so only a shared lib is doable at time of writing)
Following changes are made:
* remove 'external project' for qtwebengine target, we keep it however
for ninja ,gn and a host project
* call gn from cmake in a scripting mode during build and not configure
run, this way BUILD.gn is assembled as a build step so after
generator expressions are executed
* BUILD.gn is assembled now from 4 files:
- root template BUILD.root.gn.in
- compiler data gn_config_c.cmake, gn_config_cxx.cmake
- sources data gn_cofnig_target.cmake
* since we use gn wrapper script use gn.args file to pass arguments
instead of a command line, so this file can be now easily modified
when running gn and ninja 'manually'
* since a script mode does not support handling of properties with
TARGET as such, use the DIRECTORY scope in some of our functions
which handle GN_TARGET
* use qt_build_repo() in main CMakeFile and remove all coin and top
level build hacks
* remove 'external project' for examples and tests, this is no longer
required as all qt targets are not hidden by external project
* remove leftovers from gn feedback call used for GN_TARGET
* improve installation rules, WebEgineCore target is not by default
installed during build, therefore we need to copy resources and
translations to root so tests and examples still can be built without
a module being installed first
* adjust GN lookup paths, we look for gn in main configure and during
scripting mode when gn is executed
Fixes: QTBUG-94349
Fixes: QTBUG-94709
Fixes: QTBUG-94922
Fixes: QTBUG-94997
Fixes: QTBUG-95051
Fixes: QTBUG-95152
Fixes: QTBUG-95158
Fixes: QTBUG-95972
Task-number: QTBUG-95231
Task-number: QTBUG-95590
Pick-to: 6.2
Change-Id: I5e7a34287ee59d904103fe310fc7c6a36a8dfbc9
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add arm cross-compile basic support. CMake does not
support host builds. However we do host build with gn and
changing that would require an extra effort to keep all necessary
changes with Chromium upstream. Therefore let gn to perform
the host build for required tools and just feed gn with all the
build data.
Add new build steps:
* install gn into QT_HOST_PATH/libexec.
* run hostBuild project to get native architecture and compiler
* call PkgConfigHost to pass pkg-config paths to gn
* create wrapper script for host pkg-config to escape
yocto shell pkg config exports
This change also splits gn toolchain into 3 toolchains host,target,v8
Now hostBuild provides host and v8 toolchain in case of cross compile.
The build optimizations will follow in another patch.
Fix not existing 'boot2qt' condition and enables more test on QEMU.
Note this is tested only with yocto based images.
Task-number: QTBUG-91760
Change-Id: Ic2bea12229acc71fbd36a848e9ed4fed7e14b485
(cherry picked from commit 3a962d8a2d3b70639a195fe5fd442f6c653bbe8f)
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check the version before using gn, since some systems
can have already gn installed. In case of cross builds
gn is installed into host qt and can simply end up in /usr/bin
path of x86_64 sysroot in case of yocto builds, meaning it will
be picked up by the host system path. Moreover, findGn.cmake
is also going to be installed and should not just look for non
existing builds paths.
One can also avoid pointless recompilations of gn for every
single clean build. Gn can be easily installed by simply building
the "gn" project:
cmake path/to/qtwebengine/src/gn
cmake --build . --parallel
cmake --install .
Note setting DCMAKE_INSTALL_PREFIX and/or DESTDIR
can install gn to desired location.
Change-Id: Ie8f989c838dad2e6e7e346a4f6a861e187ec037f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
|
Add the top level cmake project and ninja and gn cmake builds.
Make ninja and gn build optional.
With qmake we had four stages during the build:
* configure (initial dependencies check)
* qmake (build ninja, build gn, run gn)
* make (compilation)
* make install
With cmake we have some limitations:
a) we need to pass the build config to gn, however cmake
evaluates generator expressions during the generation phase
this means we need a recursive call to cmake
b) qt-cmake qtbase logic (+syncqt) assumes "fixed" build locations
to handle deployment of headers and libs (it uses
CMAKE_BINARY_DIR for QT_BUILD_DIR)
c) cmake can not run twice in the same build directory
d) running recursive/child cmake, makes all generated targets not
accessible during configure time of parent's cmake
e) cmake can only "build" things for subdirectories
To deal with mentioned limitations and to keep things simple we will
split those steps into separate projects:
* SUPERBUILD - this project does dependency checks, only evaluates features
to show the build summary and passes them to EXAMPLES,LIBS,TESTS
projects, it also runs the generator expression to feed LIBS project's
cmake, it does not try to run syncqt as result of (b) and (c)
* NINJA (build ninja)
* GN (build gn)
* LIBS - projects runs simplified feature evaluation (CONDITIONS
resolved by SUPERBUILD cmake) to generate build headers (+syncqt),
it also runs gn during configure and does all libs
compilation. The project's source root must be "src" directory
as a result of (a),(b),(c)
* EXAMPLES - builds examples as a result of (d),(e)
* TESTS - builds tests as a result of (d),(e)
Each of projects will have three stages: configure, compile, install.
Task-number: QTBUG-91760
Done-With: Jüri Valdmann <juri.valdmann@qt.io>
Change-Id: I3b44decefa17f177e5e07c563796aa158a0b0ecb
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Peter Varga <pvarga@inf.u-szeged.hu>
|
