I'd much prefer to go to the audio directory to work on everything
from
portcls.sys up to mmsys.cpl. Things could be committed together
instead
of separately forcing 2 separate builds on buildbot
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
That seems perfectly reasonable to me. Control panel applets shouldn't be grouped together as they aren't related. They're just dlls. In fact, they aren't even stored together inside Windows, they're COM registered components which can live anywhere on disk. We group them together as if we're end users and are too dumb to know where they should be stored. We aren't dumb end users, we're devs who are supposed to know how things are architecture.
Imagine if Linux wasn't modularized and changes made to X or Gnome
forced
rebuilds of the kernel. It would be carnage.
ReactOS is modularized a lot more really. Linux is a ball made of interdependent threads. If they used RBuild, they would get libusb recompiled evertime a comment in the KMail app source code was changed.
Reactos is modularized in its architecture (as per NT), but it it's not modularized in its tree. If it was then csrss, win32k, gdi32 and user32 would be stored together, instead they're separated and stored with 3rd party Wine code.
As the tree grows I really don't see how the current layout will
remain
feasible. Something will have to change and I don't think hacking the build
system
around a broken tree structure is the answer.
What I really want is that if I have four modules: a, b, c and d, which could be located at any relative path inside the build tree. So what I want is being able to specify a few targets, e.g. all being a+b+c+d, kernel being a+b, minwin being a+b+c, and build specified target! So if looking into the future of my example I want minwin to include component d, I don't have to move source code files of the d component, but just mark it as belonging to the minwin group. With your example we would have to reshuffle files everytime we think module's contents should be changed.
That's a nice build feature but you'd only be implementing it due to the messy nature of the tree. You'd still have to check out the whole tree if you're only interested in building and working on minwin. Why a kernel dev would ever be interested in checking out and building notepad or shdocvw.dll is beyond me.
Also with your example of a new tree layout as an aid for better building, we can't have two targets sharing same modules unless they are physically located under one subdirectory. A substantial constraint really. And overall, it sounds like hacking our tree layout to suit sucky build system, not vice versa.
So by this argument, how would you have two win32 subsystems? (win32 and arwinss) \dll\win32 would have two user32 and two gdi32 dlls. Which one is the right one for the subsystem? Do we name one gdi32_arwinss.dll? In the suggested layout you would have \win32core\subsystems dir and have .\win32 and .\arwinss subdir. Each sub dir could then contain all the components to go with that modules, including tests frameworks.
Forget about reactos for a sec, think about how it works in industry . If you were writing a large solution made up of many components, would you structure your solution so that all the drivers, dlls, exes and tests lived in directories by type? No, what you would do it to group things together. Each exe would be stored with its dll, driver and test modules. It makes it easier to develop, build and test. It makes it easier for people to work on certain modules. It makes it easier to swap or replace things. It's how most large software projects structure their trees ... except reactos.
Ged.