Custom copy of upcoming ECMAddQCH.cmake, see https://phabricator.kde.org/D2854
for existing issues and open questions.
Details
Details
- Reviewers
staniek piggz - Group Reviewers
KProperty - Commits
- R13:f1ac05ef8d60: New: KPropertyAddQCH.cmake for creating an API dox QCH file during the build
KPropertyCore.qch generated by this: https://share.kde.org/index.php/s/y8s0oAkxUNc1dXl
KPropertyWidgets.qch generated by this: https://share.kde.org/index.php/s/anNMRKLBGDxTSPe
Diff Detail
Diff Detail
- Repository
- R13 KProperty
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Good start. Runs flawlessly.
| CMakeLists.txt | ||
|---|---|---|
| 34 | ON by default? I am wondering about overhead. | |
Comment Actions
Side-by-sided install-ability would require this:
--- src/CMakeLists.txt +++ src/CMakeLists.txt @@ -263,9 +263,9 @@ endif() if(BUILD_QCH) kproperty_add_qch( KPropertyCore_QCH - OUTPUT_BASENAME KPropertyCore + OUTPUT_BASENAME ${KPROPERTYCORE_BASE_NAME} VERSION ${PROJECT_VERSION} ORG_DOMAIN org.kde SOURCES Mainpage.dox @@ -293,9 +293,9 @@ if(KPROPERTY_WIDGETS) set(_KF5WidgetsAddons_QCH KF5WidgetsAddons_QCH) endif() kproperty_add_qch( KPropertyWidgets_QCH - OUTPUT_BASENAME KPropertyWidgets + OUTPUT_BASENAME ${KPROPERTYWIDGETS_BASE_NAME} VERSION ${PROJECT_VERSION} ORG_DOMAIN org.kde SOURCES ${kpropertywidgets_HEADERS}
| CMakeLists.txt | ||
|---|---|---|
| 34 | BTW, what's the default for KF5 for example? | |
Comment Actions
This may be not the core topic here but any ideas to improve these glitches in Assistant?
Comment Actions
This may be not the core topic here but any ideas to improve these glitches in Assistant?
It could be improved by building Qt Assistant not only with QTextBrowser, but instead with QtWebKit. Sadly there seems no option yet for QtWebEngine, only some patch for Qt Creator with that.
See issues listed at end of Summary for https://phabricator.kde.org/D2854. It is a hen & egg problem sadly. My hope is by having finally more 3rd-party QCH there will be more interest/pressure to fix both Doxygen to create JavaScript-less QCH files and/or the QCH viewer to be provided with not just QTextBrowser given the existing QCH files.
If everyone just waits until things work properly, nothing will happen in any case. At least I already got one fix into development branch of doxygen...
| CMakeLists.txt | ||
|---|---|---|
| 34 | The overhead currently is pretty small from what I experience. On my machine (SSD) the QCH generation feels to take a similar long time as an .o file generation. The current patches for KF5 also use ON as default (cmp. https://phabricator.kde.org/D3458, https://phabricator.kde.org/D3439, https://phabricator.kde.org/D3438), just nobody has yet started to review and give feedback, so currently lack of further opinions. | |
Comment Actions
OFF please here. And if @piggz agrees for KReports as well.
| CMakeLists.txt | ||
|---|---|---|
| 34 | OK, I am thinking about OFF as the default. We never know what's the reason of building: preparing package is only a tiny fraction of cases, actually one of the last. We never know if people prefer HTML of PDF docs. During development generating anything for every build is costly. I would say we can equally well document a note that developers can set to OFF but in real world there are more developers than packagers, so I believe it's somewhat better to say packagers to set it ON in README.PACKAGERS. | |
Comment Actions
workaround cmake_parse_arguments not defining variables for empty multi-var arguments