About the rbuild proposal:
In my opinion, it's not the right way to go.
From my point of view, the api and status generation tool (be it a
script or executable written in a common script language like perl, php, python or C/C++) should parse the source code and gather all information out of the original files. It's neither necessary nor smart to store un-synced redundant metadata in external files about the same. the parser simply collect the data out of the source files. I am under the impression that some want to try to add additional metadata to files like *.rbuild files, just to simplify the parsing process but on the otherside 'generate' a lot more problems by make it almost impossible to keep the data in-sync.
From a limited first point of view, it sounds great; but it reminds me
of one who is new to object oriented world and want to express everything as object or metadata. The real world is different, and it's better to keep it simple and let the parser do its task => parse the source files. Don't get me wrong, metadata are good and have it's place, but we have to make sure that we keep the balance and avoid "information"-hell.
So instead of outsource the information (developer, translator, language-info, etc.) from the source code to external rbuild files, keep the data in place where it belongs to. It's the parsers job to parse the source and extract it, and put it together in a meaningful way (generate static output, be it xml or html).
And as response to the rbuild package discussion: The whole discussion about the language and package support has gone in the wrong direction. It would be already possible to use rbuild xml files to define the BootCD, LiveCD with some extra work (replace the bootdata config files, with xml rbuild files and modify some setup code; or alternative generated the bootdata files based on xml config). The main point is that the package information should be stored in a single directory e.g. boot/bootdata, instead of adding such information to each module-rbuild-file. Having a single location, it would be a piece of cake to "fork" compilation packages (BootCD, LiveCD) and create a custom ISO file by copy&paste&modify the package xml file. Of course something for the future, our current solution is fine for now.
Additionally, I would like to point out that the statistics and/or API-docu tool should work fine on Win32 and Unix and be licensed under a GPL v2+ compatible license. So that we can put it in place to our online services (website). Furthermore, Java and dotNet (C#, VB.Net, F#, etc.) should be avoided (IMHO) for several reasons (either not-available, or too much overhead and nowhere included by default; which is pretty much the opposite of our ReactOS and especially the RosBE philosophy.
Klemens