28 Jul
2010
28 Jul
'10
1:35 p.m.
From: Ged Murphy
Sent: Tuesday, July 27, 2010 12:06 PM
To: 'ReactOS Development List'
Subject: Re: [ros-dev] Tree restructure (was: Re:[ros-diffs] [akhaldi]48236: Create a
branch forcmakebringup.)
Timo has given you various scenarios as to where the proposed system is an improvement on
the existing.
Maybe someone can give an reason as to why the current layout is better than the suggested
one?
I think it's best to do kind of a summary of pros vs. cons. I remember we spent quite
some time discussing it with him, but (Timo - correct me if I'm wrong) his
argumentation was that it's "more logical", which is quite subjective.
So you want more reasons?
Agreed about alphabetical, but that's exaggeration.
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.
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.
The proposed layout also lends itself well to the branching system we've been wanting
to work towards. Branches could be more easily assigned to specific areas and we'd be
able to give out commit access more easily.
Agreed about branching.
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.
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.
Ged.
From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of
Aleksey Bragin
Sent: 26 July 2010 23:10
To: ReactOS Development List
Subject: Re: [ros-dev] Tree restructure (was: Re: [ros-diffs] [akhaldi]48236: Create a
branch forcmakebringup.)
Please, this would be my last reply to this thread. Yet another time I'm getting an
answer that reshuffling files in the directory makes build time shorter. Seriously, am I
writing with background and foreground text colors being set to the same value or what?
Is there any real, serious reason to break compatibility with all existing branches, make
modules harder to find, whatever else, BESIDES hacking around a broken build system which
can't have proper grouping? I proposed to properly solve this with either sysgen,
cmake or anything else. With a build system which does not suck. Not with a build system,
where you need to adjust file paths in order to be able to control build process!
I'm glad to participate in a discussion about pros and cons of a proposed new tree
layout, but so far the only thing I keep listening to is that it's somehow going to
make build time shorter. Let's be honest: It won't. If a 1 liner in PSDK causes
whole tree to rebuild, it will take the same with the new layout. It will just be built in
a different order, but still all will be rebuilt, because of (somehow broken, or too
strict, or incompatible with the makefile) dependencies tracking. It won't make build
time shorter until a new build system is in place.
WBR,
Aleksey Bragin.
From: Ged Murphy
Sent: Tuesday, July 27, 2010 1:23 AM
To: ReactOS Development List
Subject: Re: [ros-dev] Tree restructure (was: Re: [ros-diffs] [akhaldi]48236: Create a
branch forcmakebringup.)
On 26 July 2010 21:29, Aleksey Bragin <aleksey(a)reactos.org> wrote:
Regarding the current layout is logical: We could sort the modules
alphabetically, that would be as "logical". But it's not reasonable.
Great, we came to an agreement: it is logical :). Reasonability is discussable...
I'm yet to hear any arguments as to how the current layout is better than the
suggested one.
As the tree grows in size it's going to become more and more difficult to manage.
Do we really have to wait until we're at a point where it takes 5 hours to build after
making a 1 line change to a PSDK file?
As far as I can tell, our current layout, by type, only serves to make modules easy to
find.
In comparison, Timo's alphabetical point is actually as reasonable as the current
layout.
Ged.
--------------------------------------------------------------------------------
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
--------------------------------------------------------------------------------
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev