Aleksey Bragin schrieb:
Ged's and Timo's ideas are expressed on that wiki page he linked earlier: http://www.reactos.org/wiki/Techwiki:File_Layout http://www.reactos.org/wiki/Techwiki:File_Layout
The problem is that change tries to fix rbuild's problems by reshuffling various modules in the tree structure, when the proper solution is to fix the build system itself. A decent build system supports modularization concept in such a way that doesn't require moving actual files around every time we add a new module or group of modules.
No, you seem to misunderstand the points of the restructure.
First: Rbuild sucks and noone is fixing it. In fact I seem to be the only one working on rbuild at all from time to time and I hate rbuild, I hate makefile stuff. We have sysgen, but noone is working on that either. Now there is an attempt to use CMake, which sucks as well and which will not solve the problems we have, even if ever anyone will be able to build our whole tree with it, which I still doubt. Example: someone adds a new file to drivers/wdm/multimedia/audio/blabla/blabla.rbuild. As a result rbuild rebuilds the makefile and with a chance of 30% starts rebuilding headers, recompiling rbuild, again rebuilding the makefile, compiling the whole damn tree.
It's also not the responsibility of the build system to handle the development process or compensate for a broken file layout. The build system won't help our buildbot when we always do a clean rebuild of the whole branch. The build system won't help us with managing branches, it won't help with updating individual components. Example: I want to commit a small fix in win32k, which goes together with a line in user32. To be able to commit both, I need to start my commit from the reactos root folder and wait 3 minutes before TSVN has finished scanning my WC. Then TSVN tells me I have to update my WC, because someone else comitted to win32k. I can't just update win32k, because it relies on a change in gdi32 as well. So I need to update that as well. So I either end up cherry picking individual modules that I update, which ends up in version fragmentation or I update the whole WC and then recompile everything, because someone else has added a file to blabla.rbuild or fixed a typo in some header.
I remember once someone told me not to commit so often, because buildbot couldn't handle building all those revisions... And they were to a branch. Well that problem is solved, but comitting 10 times in a row to paint will still make buildbot compile crt, rtl, ntoskrnl and everything 10 times in a row, although it's completely unaffected. How do we solve that with rbuild if we always do clean rebuilds. I wonder how long it takes to build the whole windows sources. I don't think at MS they will recompile the whole code base everytime someone makes a change to paint. Doing so is ridiculous. That's why these things need to be seperated. Just "seperating" it with a build system, while the actual files are still being spread all over the place just doesn't work.
Regarding the current layout is logical: We could sort the modules alphabetically, that would be as "logical". But it's not reasonable.
Regards, Timo