[ros-dev] rosapps

[Timo Kreuzer]

Yes that might already hit it, when it's properly implemented.
Though I think a physical seperation might add some additional
advantages, especially when
it comes to managing an increasing mass of resources.

One thing that has bugged me when working with the x64 branch was that
everything depends on so much other stuff.
It's not possible to disable the apps folder, as the dll folder depends
on it and vice versa. Some hacking was required
So I added the usermode rbuild switch. still you can't just
remove/diable something. And when you want to clean parts of your
local copy, you will have to rebuild or at least relink all stuff that
depends on it.

make ntdll clean
make
will relink all usermode dlls :(

So moving the import libraries to an sdk module group would unlink the
modules and make it easier to
build/clean parts of them without effecting the others.

And for some reason, changing one rbuild file will at random times lead
to a recompile of rbuild which will then lead to a recompile of
everything else. and that sucks a lot.

ok it finally ends up with ranting about rbuild....


Aleksey Bragin schrieb:
> 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
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20090310/dafe257c/attachment.html