| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the advent of QDoc's `tst_validateQdocOutputFiles` test, we now
have a better way to test QDoc's generated output. One of the test
cases in the new test represents a rather comprehensive documentation
project. This project was adopted from `tst_generatedOutput`, where it
is known as `TestCPP`.
This change removes a configuration file from `tst_generatedOutput`
and adapts the aforementioned documentation project such that the
behavior remains tested. Expected output files are modified
accordingly.
Task-number: QTBUG-119500
Pick-to: 6.7
Change-Id: Ifa3c7c4fcbfd05c9ed45f989286fabe79995ad4b
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The \deprecated command accepts a version string as a bracketed argument
representing the version in which the API element was deprecated.
Add a check for whether the argument represents a future version.
The version string is checked against the 'version' .qdocconf variable.
If it's deemed to be a future version, do not mark the Node instance
as deprecated; it will be kept as part of the API reference, instead
of moving it to the separate 'Deprecated members' page.
Tag such nodes with 'until <version>' both in the summary list and
detailed documentation (signature), and add an auto-generated
sentence into the documentation, for example;
This function is scheduled for deprecation in version 6.9.
Use QVersionNumber for the version comparison. If QVersionNumber cannot
interpret both the 'version' configuration variable and the \deprecated
argument, mark the Node instance as deprecated.
[ChangeLog][QDoc] The \deprecated command now correctly handles
deprecations in a future version.
Fixes: QTBUG-121378
Change-Id: I094699257534902e45edf4fed55cf6ff06021f12
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
While moving the `testcpp` test project from `tst_generatedOutput` to
the new data-driven `tst_validateQdocOutputFiles` test for QDoc, it
became apparent that several test projects/test configurations
essentially did the same work, with trivial differences, such as adding
an output format, enabling DocBook extensions, etc.
While moving the `testcpp` test project and it's related projects seemed
like a good first step, it quickly became clear that the `tagfiles` test
project already contained essentially the same source files, and was
only missing the output format specific variations and QHP
configuration. After unifying that and building the two projects,
After consolidating the test data for the `testcpp` project, it's clear
that the projects are duplicates:
[testdata]$ diff -qr testcpp tagfiles
Only in tagfiles/expected/html: testtagfile.tags
Only in tagfiles/expected/webxml: testtagfile.tags
Only in tagfiles: tagfiles.qdocconf
Only in testcpp: testcpp.qdocconf
Therefore, merge them all into the `tagfiles` project. Finally, rename
the `tagfiles` test project to give it a more descriptive name.
In the end, this allows dropping the following test cases from
`tst_generatedOutput`:
- htmlFromQml
- webXmlFromCpp
- webXmlFromQml
- docBookFromCpp
- docBookFromQml
- docBookWithExtensionsFromCpp
- docBookWithExtensionsFromQml
- examplesManifestXmlAndQhp
Task-number: QTBUG-119500
Change-Id: Icd59844dc3e4bd96b50105f24559c5746f885673
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
|
