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(a)reactos.org>
Sent: Friday, March 27, 2009 1:49 PM
To: "ReactOS Development List" <ros-dev(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev