[ros-dev] rosapps
Alex Ionescu
ionucu at videotron.ca
Mon Mar 9 13:06:05 CET 2009
I'm attaching some rbuild files I used before:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-build.rbuild
Type: application/octet-stream
Size: 393 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-core-base.rbuild
Type: application/octet-stream
Size: 1042 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-core-drivers.rbuild
Type: application/octet-stream
Size: 2022 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-core-kernel.rbuild
Type: application/octet-stream
Size: 1194 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-win32-core.rbuild
Type: application/octet-stream
Size: 4747 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment-0004.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-win32-extra.rbuild
Type: application/octet-stream
Size: 313 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment-0005.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReactOS-win32-user.rbuild
Type: application/octet-stream
Size: 1680 bytes
Desc: not available
Url : http://www.reactos.org/pipermail/ros-dev/attachments/20090309/a4c17afe/attachment-0006.obj
-------------- next part --------------
On 9-Mar-09, at 4:40 AM, Aleksey Bragin wrote:
> It might be implemented as a subset of "make XXX", where XXX would be
> that core, drivers or anything like that - but all from one tree,
> just a different sets. Otherwise than that, splitting them physically
> into different modules is going to only hurt the development, not
> make it easier. I already thought about that, but I'm afraid it won't
> work.
>
>
> Oh, actually, Marc Piulachs already implemented all of that in his
> platform builder, so he's able to pick necessary modules with a click
> of a mouse, and produce an installation CD consisting of such
> "modules", and it indeed works. It just is not separated physically
> in the tree itself.
>
>
> WBR,
> Aleksey Bragin.
>
> On Mar 9, 2009, at 4:20 AM, Timo Kreuzer wrote:
>
>> I would even like to go one step further in the long run.
>>
>> The current situation is that rosbuild takes about 10 minutes for a
>> build. With adding more code and more modules to our codebase, this
>> time will increase. If we wanted to do something like auto-
>> rejecting commits that break build it would lock the commit process
>> for this time on every commit.
>>
>> Also as we get more developers and maybe start forming teams or
>> whatever, things will get problematic with our current "monolithic"
>> approach.
>>
>> We should think of changing the build process, so that not the
>> whole system is rebuild everytime someone changes one module.
>> We currently treat reactos like one huge module, but it isn't. It's
>> a bunch of more or less independent things. A change in a usermode
>> dll should not lead to an notskrnl recompile, it just doesn't make
>> sense and only wastes time.
>>
>> I think it would be better to seperate the components from each
>> other as much as possible and only compile the modules that have
>> been changed.
>>
>> Of cause all modules somehow depend on each other, but mostly
>> through well defined interfaces. These are exposed by the headers
>> and import libraries. And those 2 are the problem atm.
>> It might be a good idea to completely separate the sdk from the os
>> itself. The sdk would contain both the headers and the spec files
>> to build the import libraries. If we made sure these are in a good
>> shape, we would eleminate most interdependencies as they should
>> only rarely change.
>>
>> We could try to split the current reactos tree into seperate trees,
>> maybe like this:
>> sdk: headers, import library definitions, crt
>> core: rtl, freeldr, hal, ntoskrnl, boot drivers, ntdll, smss
>> drivers: other hardware drivers
>> win32core: win32k, video drivers, gdi32, user32, csrss
>> win32dll: the other win32 dlls
>> sound: everything related to sound
>> network: everything related to network
>> reactx
>> services
>> apps
>>
>> Some of these trees could be optional, like network, sound, reactx
>> It might even allow to create a bootable core system without win32
>> stuff, booting into a simple native console.
>> Working with branches might as well profit from this.
>>
>> Just my 2 cents,
>> Timo
>>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Best regards,
Alex Ionescu
More information about the Ros-dev
mailing list