9 Mar
2009
9 Mar
'09
2:15 a.m.
Hi!
2009/3/8 Timo Kreuzer <timo.kreuzer(a)web.de>de>:
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
Core DLLs: ntdll, kernel32, gdi32, user32 and sometimes advapi32.
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