Hi Klemens, a few comments under your own lines:
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.
If you can say "un-synced redundant metadata" is that you haven't got the idea yet. Actually parsing is the wrong way to go , is complicated , takes a lot of resources , is slow and error prone , parsers exists because we live in a un normalized world. Why do you think RDBS or metadata were invented for?
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.
If this "some" is me, as I already said you parsing is not the problem, It has nothing to do with it. It has to do with normalizing and organizing the information we already have in the more correct possible way. As I already said multiple times I'm trying to describe the information contained on the SVN (sources , languages ..) in the most abstract and neutral possible manner so we can create more powerful tools that as a side effect automate the most possible amount of things.
Please can you take a few seconds to think and answer me what's the difference between <file>source.c</file> and <localization isoname="en-US">en-US.rc</localization>? Exacly none.
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).
In my opinion is just the opposite, move the information where it really belongs, when you talk about a developer or a translator working in a piece of code you refer them in a particular context , in this case a whole module, the same for mantainers or translators , they are global to the module.
Once again, the data extracted from parsing is not TRUE metadata just meaningless strings that you can guess or interpret : "author : jdoe" , "author : jhondoe" , "author : jhon doe" are 3 different persons and <author>Jhon Doe</author> just one , I think it's obvious.
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.
I think you have a small confusion here, the bootstrap module (btw It has already been there for more than a year I only slightly modified it) has nothing to do with packages, It is used to place the required files (dlls , exe , sys , etc..) that are required to boot reactos from a bootcd.As I already explained I only removed the hardcoded "reactos" folder on the CD to an architect based one (i386 on a IA32 build, PPC on a PowerPC build , ...) no more no less.
I would suggest to take a deeper look at my code/changes so we can have a more productive discussion, would be glad to answer and clarify all your questions.
Regards, /Marc