I implemented a similar feature on my c# rbuild clone and It worked quite well.
I had a new module type 'modulegroup' which was basically a list of other modules , for example:
<module name="opengl" type="modulegroup" description="OpenGL support"> <requires>core</requires> <requires>mesa32</requires> <requires>glu32</requires> <requires>opengl32</requires> </module>
<module name="core" type="modulegroup" description="Core OS"> <requires>framebuf</requires> <requires>vbemp</requires> ... </module>
In this sample a virtual module "opengl" was created and it was referencing "mesa" , "glu32" and "openg32" but at the same time was also importing all modules referenced by "core" which are the 150 modules required to build a functional reactos install image.
typing "make opengl" would only build arround 170 modules and create an iso image with them inset of building the other 750 modules obviously saving a lot of build time.
My implementation was written from scratch and was full functional producing a bootable ISO image arround 6 months ago. With a little more work can be good replacement for our old , dusty c++ implementation. More information about it on my website.
Regards, /Marc
-------------------------------------------------- From: "Aleksey Bragin" aleksey@reactos.org Sent: Friday, March 27, 2009 1:49 PM To: "ReactOS Development List" ros-dev@reactos.org Subject: Re: [ros-dev] rosapps
On Mar 26, 2009, at 2:02 PM, KJK::Hyperion wrote:
Aleksey Bragin wrote:
We have chatted with Art a bit on this topic yesterday, and our opinion seems to be that trunk/reactos should include all stuff included in a default Windows, but with a modification to rbuild to allow tags for each module, and later build by tags.
tags are a bad idea. We don't need any more goddamn attributes for module elements. What you want is collections of modules, or in other words, makefile targets other than "all". Object-oriented is a terrible, terrible paradigm for build systems
Make me a list of the build profiles you want supported, and I'll work on it. I'll make each of you a tuna sandwich too, anything but a new godforsaken attribute for module elements
We can call it another way, but what I mean is "marking" a module as belonging to some group, either via a stupid group="blah" attribute, or via <group name="blah">...</group>. And it should be easy to turn on/off building of certain groups via some central groupstobuild.rbuild file.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev