[Bug 175581] New: no documentation for KDE_IS_VERSION and the hole kdeversion.h avaible

[Tim Fechtner]

http://bugs.kde.org/show_bug.cgi?id=175581

           Summary: no documentation for KDE_IS_VERSION and the hole
                    kdeversion.h avaible
           Product: kde
           Version: unspecified
          Platform: unspecified
        OS/Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: unassigned-bugs at kde.org
        ReportedBy: timmi at gmx-topmail.de


Version:            (using KDE 4.1.3)

The KDE API documentation (for example at api.kde.org) hasn't any information
about the macro KDE_IS_VERSION and all the other macros that are defined in
kdeversion.h. (That's bad, because these marcos are very usefull, and it took
me much time and a question in a forum to find out the existence of such
macros.)

That's because kdeversion.h isn't avaible in the sources, but is generated on
build time by CMake from the file kdeversion.h.cmake
(http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/util/kdeversion.h.cmake?view=markup)
As this file doesn't derminate on .h or .cpp or similar, but terminates on
.h.cmake, it isn't indexed by doxygen.

I don't know much about the build system and documentation system, but wouldn't
it be possible to add "*.h.cmake" to the list of valid file extension in
Doxyfile - so that Doxygen indexes also this file? Using "*.h.cmake" would make
shure that not every .cmake file is indexed, but only these who will be
transformed in header files. Advantage: simple solution. Disadvantage: The file
will get documentated in it's pre-CMake version, and not in it's post-CMake
version (with minor differences, in generally there isn't changed too much by
CMake).

Okay, it would be nicer to index the real kdeversion.h file like it is
generated by CMake - however I don't know how to realise this easyly...


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.