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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
