The documentation warning configurations marked with the TestDocs
feature will now use the new doc tools building instructions from
qtbase, instead of using the provisioned qdoc tools when checking the
documentation for warnings.
This means that each qtbase integration will build the doc tools
from qttools/dev/HEAD and use those built tools associated with that
qtbase sha1 integration to check documentation in all other
repositories.
The doc tools will be rebuilt whenever a new qtbase integration
starts.
See the qtbase commit 1f646bb978ed94c25f6224e801779c929096c0ae for
more details.
Task-number: QTBUG-128730
Change-Id: I5a981afa9ec2c2b3a5c519b961e566ec5d2cc925
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We have two builds we need to cover:
1. Documentation testing, aka 'DocTests' feature
This feature builds docs for every submodule during module
integration, using externally provisioned doc tools.
2. Offline documentation building, aka 'Documentation' feature
This feature builds documentation for use in e.g. Qt Creator
For both these builds we only need a single config to handle them.
The initial configs were based on Ubuntu 22.04, but with the addition
of Ubuntu 24.04, and splitting up X11 and Wayland testing, these configs
multiplied, which is not needed. The inclusion of 'documentation' in
the various test configs was also needlessly confusing when e.g.
looking at test failure results in Grafana.
The previously named 'documentation' configs for Ubuntu have been
renamed to 'developer-build', as this is the significant difference
to the non-developer-build config.
There's still two issues with these configuration:
1. The DocTests configuration also runs the Qt auto tests.
The DoNotRunTests and DisableTests feature flags would
seem to be relevant for skipping the auto-test step in
the coin test instructions, but these are hard coded in
coin to skip the entire test workitem.
2. The offline doc builder builds Qt and tools from scratch
A better approach would be to depend on another build
and just configure and build docs, but doing so requires
more investigation.
Change-Id: I5a041dec697424b85d3b1588cd6e77a80551d2eb
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Previously configurations with -make examples in their configure args
were building examples as part of the Qt library build. This has some
downsides:
- we don't build examples as a separate project, thus not ensuring
that we build examples as our users would
- qt cmake deployment api can't be used due to various limitations in
our tooling
Use the new qtbase instructions to instead build examples as a
separate project in a separate build directory, after Qt is built and
installed. This is similar to how we build standalone tests.
The new instructions are activated by the StandaloneExamples features.
It is opt-in as opposed to standalone tests, so we can disable the
feature in case any regressions happen.
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I71b37b91ed09bcc0797841adf0df84cc0b111fd7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The 'headersclean' flag is not a "feature" anymore, so qtbase doesn't
propagate it for other repositories. CI no need to set either
INPUT_headersclean=ON or add -headersclean flag to the
qt-configure-module script command line.
Task-number: QTBUG-121722
Change-Id: I6970d6a04dd51ad4d3df114212f6410b80ddc6a1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I can see why de8a8879bd added
-no-warnings-are-errors (QtWayland tests were full of [=] implicitly
capturing *this), but I've fixed those now, so re-add -Werror.
Pick-to: 6.6 6.5
Change-Id: I48db4cee08bd766b2b00949cdb09a4dd97214298
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
