From ReactOS

My ideas for stuff, which isn't in rbuild yet

• Enabling and disabling modules without reparsing all .rbuild files or changing directory.rbuild files to exclude some from the process.
  IMO, this should be done with a property or in an extra file, which marks all enabled/disabled modules.
• Automatic generation of manifest files for Versioning (like enabling Common Controls 6.0).
  This needs to be done differently for GCC and MSVC, because MSVC 2005 and later use the /manifestdependency parameter and GCC still wants an XML file embedded as a resource.
• Put the code for reading rbuild files and building a module tree into a separate library, so that it can be easily reused by other apps.
  This would enable us to:
  • Write a make config/menuconfig/xconfig/kdeconfig like system for configuring the build, which is truely separated from the actual build tool.
    My idea for this system would be to define options with a short explanation in the .rbuild file. The settings should then be written into autogenerated "config.h" files. (using #define's)
  • Write a tool, which outputs documentation like a module overview or dependency tree based on the .rbuild files. Marc already had an example a while ago, how something like this could look.
    With the current rbuild design, this could be theoretically done in a backend, but then this backend would be compiled into rbuild everytime, even if it's not needed for the build process. Therefore a separated tool would be better in my opinion.
• "rsrc.rc" files should be abandoned from the source tree. Instead references to all .rc files should be added to the .rbuild files of a module and tagged by their language. Such a change has already been done in the "rbuild" branch. (see r29785)
  This has two advantages:
  • If someone doesn't want to build all languages, he could set a property and disable some.
  • The .rc files don't necessarily need to be compiled into one big application file.
    If we have them separated this way, it would be easy to build one application file and all languages into individual DLL files.
• Build families as we already have in the "rbuild" branch. (see r30469)
• The hardcoded calls for creating the ISO files should be phased out of the rbuild app.
  If this isn't doable reasonably, the code should at least be updated to the version in the "rbuild" branch, which creates correct architecture-dependent folders (like "i386" and "ppc") instead of one "reactos" folder.
• In all cases, rbuild should be tightened as least as possible to the ReactOS source tree, so that it may be used for other projects as well.

Colin Finck 15:28, 14 May 2008 (UTC)

My ideas for stuff, which isn't in rbuild yet

I agree with most of the ideas of this paper although there are some things which I don’t agree with:

• rbuild syntax is based in XML so yes, it's verbose but we have to live with it. Trying to turn <if property="ARCH" value="i386"> into arch="i386" has not significant benefit but will complicate the code to handle it , specially validation , the current syntax for <if is very simple to parse as we expect two attributes with a fixed value. The suggested syntax will make the parsing and validation very much complicated. My proposal here is to integrate an expression parser to rbuild so we can use *real* and powerful conditional code to handle more complex logic for example : <if true="$(ARCH) == 'i386' && ($ARCH) == 'xbox'"> so if the evaluated condition is true child nodes are

exectued.

Things I absoluty agree:

• Module types - current syntax is bad, diferent module types have different valid properties and there is no simple way to validate them without a bunch of checkings. We have to encapsulate ever module type in its own class and use OOP and take advantage of inherency. Same thing for other objects. It was already on my plans RBuild core (parser and base classes) is not bad at all moving that functionality to a library whould be great, Backends are terrible

• New Make-MSVC backend: use make and MSVC command line tools

• MINGW backend: a mess , lots and lots of copy pasted code , full of hacks , We are not using OOP but a lot of ifs and switchs . Every time anyone need to update the backend have to be very carefully to not break anything. Implementing new modules requires to add a lot of supporting code (checks) so it's very error prone. Once again if we were using OOP we weren't facing that problem. Probably MINGW will have to be rewriten from scratch.

• Reduce man work. Don't do ANYTHING by hand if it can be automated. Every time I try to introduce a new feature to reduce human intervention I get the typical complain : "Oh , rbuild syntax is getting more and more complicated" . Compiling , linking and configuring an operating system is not a simple task and lots of validations , dependencies, .. need to be taken into account. New elements will have to be introduced so ,,, I would say "sorry but you will have to live with it"

Additional ideas:

• Extend rbuild role to platform configuration and not simply to build code. rbuild should not simply turn source code into object code but also generate the supporting configuration for the platform being built. TxtSetup , SysSetup , hivecls , hivedef , hivesft and hivesys should not be static files but dinamically created depending on the modules being selected to build. Actually it's getting there. <autoregister , <installfile , my recent additions to module type 'keyboardlayout' are a step in this direction. The idea is to end up having a linux like 'menuconfig'

New Name

This article should get a new/more professional/more wikified name. Iyeru 15:06, 10 June 2008 (UTC)

The article is already available under the "rbuild sucks" alias. --Kjkhyperion 14:50, 28 November 2009 (UTC)