I haven't been contributing much code to the reactos C++ build engine (RBUILD) lately but I have been improving my own C# implementation of it. Since it's truly OOP and well designed adding and testing new features is easier than with our buggy and messy rbuild.

I use my C# implementation as a playground. My intention is to slowly extend rbuild to turn it in to a build and configuration engine (not only generate the makefile but also the registry and setup files depending on the modules being included).My build engine partly does it so I wanted to show some of the advantages and new features I will be adding to RBUILD in the following months. Some of them are already implemented on my rbuild branch (waiting for Colin to help me merging it back to trunk) while others are still to be coded.

- We have arround 800 modules (including tests)
- Diferent Bootable ISO images with diferent modules and default settings are being build from the same unmodified codebase. see http://www.marcpiulachs.com/reactos/
- Updated reports : http://www.marcpiulachs.com/reactos/core/default.htm
- Automatic dependecy tracker reports .See for example : http://www.marcpiulachs.com/reactos/core/ntoskrnl.htm
- My testing reveals that the minium amount of modules required to produce a bootable ReactOS ISO is currently about 190. see : http://www.marcpiulachs.com/reactos/core/platform.htm. I have been unable to boot with less modules , by tweaking the registry it can probably be reduced even more.
- Even our OS is quite modular we make alot of bad assumptions in our code. (We are not microsoft , we don't have to package our OS in a determinate manner due to obscure marketing reasons. some day reactos should be able to run on a standard pc , on a ARM based device with 64Mb of ram or as headless network router with no GUI at all so don't assume notepad or application XYZ to be present unless it's a *core* component)

- All Iso images are created with an unmodifed code base except for two bugs I fixed in syssetup and setupapi
- Our modules are not very configurable, we should use more defines to turn on and off not desired code at build time. (see linux kernel and xconfig)