Integrating kf5dot and kapidox

[Aurélien Gâteau]

On Tue, Jan 14, 2014, at 6:53, Alex Merry wrote:
> On 14/01/14 08:58, Aurélien Gâteau wrote:
> > On Mon, Jan 13, 2014, at 14:34, Alex Merry wrote:
> >> On 13/01/14 21:36, Aurélien Gâteau wrote:
> >>> Second, api.kde.org deployment. kf5dot-prepare needs to be able to run
> >>> CMake on the source code. @Allen: is it possible to do this on
> >>> api.kde.org?
> >>
> >> kgenapidox could potentially extract info from the build dir,
> >> incidentally.
> >>
> >> In particular, the generated version files could be used to get a
> >> project version
> > 
> > How would you do that?
> 
> Grab it out of the framework_version.h file or out of the
> KF5FrameworkVersion.cmake file.

Oh right, good point. This would remove one place to bump version
numbers.

> >> and the build dir could be added to the INPUT
> >> directories to parse generated files.
> > 
> > Do you have examples of files where this would be interesting? Since
> > generated files, by definition, do not have any documentation, I can't
> > think of any useful example (but I could be wrong of course)
> 
> The old script certainly ran kconfig_compiler on the sources.  I'm not
> sure how much useful documentation was extracted as a result, though.

Ah true, one can document the config entries. I hadn't noticed it ran
kconfig_compiler. I don't expect frameworks to expose kconfig-generated
classes as public API, but it probably makes sense to support this for
code with less strict BC rules.

> Also, it is not in the definition of generated files that they do not
> have documentation.  They could inherit documentation from their input
> files, or be given documentation by the generating tool.  Some thought
> would need to go into making sure we only documented useful (eg:
> installed) files, though.

True.

Aurélien