26 Jul
2010
26 Jul
'10
8:11 p.m.
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