Re: [ros-dev] Tree restructure

[Ged Murphy]

> >   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.