28 Jul
2010
28 Jul
'10
2:45 p.m.
That made for hard reading.
I've split my original points up so anyone following this can understand it.
I'll reply when I have some time :)
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 ofa 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.
Id 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 wasnt 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 weve
been wanting to work towards. Branches could be more easily assigned to
specific areas and wed be able to give out commit access more easily.
Agreed about
branching.
As the tree grows I really dont see how the current
layout will remain
feasible.
Something will have to change and I dont 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 belocated 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