In D15251#322168, @kossebau wrote:

...as well as request to finally enable BUILD_QCH on CI, so this is covered.

I wondered why that's not the case. I, for one, would welcome it.

Please note that even if the generation of QCH files is enabled on the CI system, the resulting artifacts won't be made available outside the CI system itself.
Availability of these files beyond the CI system would depend on separate work to improve api.kde.org, for which we're still looking for someone.

In D15251#322202, @bcooksley wrote:

Please note that even if the generation of QCH files is enabled on the CI system, the resulting artifacts won't be made available outside the CI system itself.
Availability of these files beyond the CI system would depend on separate work to improve api.kde.org, for which we're still looking for someone.

Sure. These QCH files generated by ecm_add_qch are not what should end up on api.kde.org, but what should end up mainly in packages of (linux) distributions, same like docbook manuals for users.

That being said, given that the Online and Offline documentation should be essentially the same thing, it may be worth looking into basing the tooling for API.kde.org and utilising the QCH build process (however that works) to generate both the website version as well as the QCH files it offers for download.

In D15251#322205, @bcooksley wrote:

That being said, given that the Online and Offline documentation should be essentially the same thing, it may be worth looking into basing the tooling for API.kde.org and utilising the QCH build process (however that works) to generate both the website version as well as the QCH files it offers for download.

Very much agree to idea of deduplication.

When it comes to providing QCH files from api.kde.org, there are multiple opinions though. My own is that QCH files should be part of the distributed product (e.g. in packages from distributions), not something offered separately and which needs manual updating by the user and extra checking to match the version of the library products one is currently using.
Not sure why some people seem to think differently here when it comes to QCH files about API of KDE products, seems people have different needs and workflows. For comparison, the Qt QCH files are not available for download from docs.qt.io, unless I missed something.

Yeah, unfortunately getting consensus that we shouldn't be distributing them is difficult - I suspect the issue is that for the most part people are used to building all of our software on their system and therefore don't have the necessary tooling or options supplied to CMake to ensure that the API Documentation is built locally as part of their builds - and therefore expect to be able to get it from api.kde.org.

Given that the jump from web accessible docs to QCH downloadable files isn't much it doesn't bother me too much though as long as the process for doing so is well maintained.