Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch for cmake bringup.

[Ged Murphy]

This may be a good time to restructure the tree?
http://www.reactos.org/wiki/Techwiki:File_Layout
<http://www.reactos.org/wiki/Techwiki:File_Layout>
This will make ros much more modular and allow things like minwin to be
built.

Ged.

On 24 July 2010 19:52, &lt;akhaldi(a)svn.reactos.org&gt; wrote:

>   Author: akhaldi
>  Date: Sat Jul 24 18:52:44 2010
>  New Revision: 48236
>
>  URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev
>  Log:
>  Create a branch for cmake bringup.
>
>  Added:
>     branches/cmake-bringup/   (props changed)
>       - copied from r48235, trunk/reactos/
>
>  Propchange: branches/cmake-bringup/
>
>  ------------------------------------------------------------------------------
>  --- bugtraq:logregex (added)
>  +++ bugtraq:logregex Sat Jul 24 18:52:44 2010
>  @@ -1,0 +1,2 @@
>  +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))?
>  +(\d+)
>
>  Propchange: branches/cmake-bringup/
>
>  ------------------------------------------------------------------------------
>     bugtraq:message = See issue #%BUGID% for more details.
>
>  Propchange: branches/cmake-bringup/
>
>  ------------------------------------------------------------------------------
>     bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID%
>
>  Propchange: branches/cmake-bringup/
>
>  ------------------------------------------------------------------------------
>  --- svn:ignore (added)
>  +++ svn:ignore Sat Jul 24 18:52:44 2010
>  @@ -1,0 +1,14 @@
>  +*.iso
>  +makefile.auto
>  +makefile-*.auto
>  +config-*.rbuild
>  +obj-*
>  +output-*
>  +reactos
>  +reactos.*
>  +RosBE-Logs
>  +*.sln
>  +*.ncb
>  +*.suo
>  +versionreport.xml
>  +config.rbuild
>
>  Propchange: branches/cmake-bringup/
>
>  ------------------------------------------------------------------------------
>  --- svn:mergeinfo (added)
>  +++ svn:mergeinfo Sat Jul 24 18:52:44 2010
>  @@ -1,0 +1,4 @@
>  +/branches/header-work:45691-47721
>  +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064
>  +/branches/ros-amd64-bringup:36852
>
>
> +/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882
>
>  Propchange: branches/cmake-bringup/
>
>  ------------------------------------------------------------------------------
>     tsvn:logminsize = 10
>
>
>

[Olaf Siejka]

Anything that will bring more efficiency into trunk as well as remove
unused/dead code is worthy of time. Not to mention that trunk gets bigger
with almost every day whereas both official and my buildbot machines are not
getting faster.

My motion would be cleaning up http://svn.reactos.org/svn/reactos/trunk/ so
it contains only code buildable by ROSBE. Right now it is trunk,tests and
apps but would get bigger if we modularize trunk and move code around.

By accomplishing that we can make buildbot setup more precize, by setting
svn scheduler to this directory, being sure that only buildable code will
trigger the build. At the moment we have a tough choice between limiting
ourselves only to ros main tree in
http://svn.reactos.org/svn/reactos/trunk/reactos or allow changes to
documentation, irc, rosdocs, tools and wallpaper directories trigger the
build as well. It ends up in heavy hacking if you want trunk+rostests
only...

2010/7/25 Ged Murphy <gedmurphy(a)gmail.com>

>   This may be a good time to restructure the tree?
>  http://www.reactos.org/wiki/Techwiki:File_Layout
>
>  This will make ros much more modular and allow things like minwin to be
>  built.
>
>  Ged.
>
>  On 24 July 2010 19:52, <akhaldi(a)svn.reactos.org> wrote:
>
> >   Author: akhaldi
> >  Date: Sat Jul 24 18:52:44 2010
> >  New Revision: 48236
> >
> >  URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev
> >  Log:
> >  Create a branch for cmake bringup.
> >
> >  Added:
> >     branches/cmake-bringup/   (props changed)
> >       - copied from r48235, trunk/reactos/
> >
> >  Propchange: branches/cmake-bringup/
> >
> >  ------------------------------------------------------------------------------
> >  --- bugtraq:logregex (added)
> >  +++ bugtraq:logregex Sat Jul 24 18:52:44 2010
> >  @@ -1,0 +1,2 @@
> >  +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))?
> >  +(\d+)
> >
> >  Propchange: branches/cmake-bringup/
> >
> >  ------------------------------------------------------------------------------
> >     bugtraq:message = See issue #%BUGID% for more details.
> >
> >  Propchange: branches/cmake-bringup/
> >
> >  ------------------------------------------------------------------------------
> >     bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID%
> >
> >  Propchange: branches/cmake-bringup/
> >
> >  ------------------------------------------------------------------------------
> >  --- svn:ignore (added)
> >  +++ svn:ignore Sat Jul 24 18:52:44 2010
> >  @@ -1,0 +1,14 @@
> >  +*.iso
> >  +makefile.auto
> >  +makefile-*.auto
> >  +config-*.rbuild
> >  +obj-*
> >  +output-*
> >  +reactos
> >  +reactos.*
> >  +RosBE-Logs
> >  +*.sln
> >  +*.ncb
> >  +*.suo
> >  +versionreport.xml
> >  +config.rbuild
> >
> >  Propchange: branches/cmake-bringup/
> >
> >  ------------------------------------------------------------------------------
> >  --- svn:mergeinfo (added)
> >  +++ svn:mergeinfo Sat Jul 24 18:52:44 2010
> >  @@ -1,0 +1,4 @@
> >  +/branches/header-work:45691-47721
> >  +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064
> >  +/branches/ros-amd64-bringup:36852
> >
> >
> > +/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882
> >
> >  Propchange: branches/cmake-bringup/
> >
> >  ------------------------------------------------------------------------------
> >     tsvn:logminsize = 10
> >
> >
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Zachary Gorden]

I also support a reshuffling of the directories, but not in the cmake
branch.  Let that be used JUST for getting cmake up and running and if/once
that is merged into trunk, then we look into changing the structure.  Best
not to complicate one task by adding more to it.

[Jérôme Gardou]

wasn't there already a branch for that task?

Zachary Gorden wrote:
>   I also support a reshuffling of the directories, but
> not in the cmake 
>  branch.  Let that be used JUST for getting cmake up and running and 
>  if/once that is merged into trunk, then we look into changing the 
>  structure.  Best not to complicate one task by adding more to it.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Aleksey Bragin]

Yes, there is no sense in doing two mainly unrelated very big tasks simulteneously. Also
my own opinion still hasn't changed - existing layout is quite logical (there are
exceptions, but they are everywhere), and any modularization could be achieved already
with existing tools like sysgen.

Let cmake branch be actual cmake experiment, not an awesome attempt to fix whole ReactOS
at once 

WBR,
Aleksey Bragin.



From: Zachary Gorden 
Sent: Sunday, July 25, 2010 9:45 PM
To: ReactOS Development List 
Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.


I also support a reshuffling of the directories, but not in the cmake branch.  Let that be
used JUST for getting cmake up and running and if/once that is merged into trunk, then we
look into changing the structure.  Best not to complicate one task by adding more to it.



--------------------------------------------------------------------------------


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

The logical layout is exactly what is wrong with the tree. The tree
is currently laid out in a manner which you would expect someone who doesn't
understand NT architecture. Things are laid out by type instead of by
architecture.
It makes building individual areas of the operating system very difficult.

On 25 July 2010 19:03, Aleksey Bragin <aleksey(a)reactos.org> wrote:

>    Yes, there is no sense in doing two mainly unrelated
> very big tasks
>  simulteneously. Also my own opinion still hasn't changed - existing layout
>  is quite logical (there are exceptions, but they are everywhere), and any
>  modularization could be achieved already with existing tools like sysgen.
>
>  Let cmake branch be actual cmake experiment, not an awesome attempt to fix
>  whole ReactOS at once [image: Улыбка смайлик]
>
>  WBR,
>  Aleksey Bragin.
>
>
>   *From:* Zachary Gorden <drakekaizer666(a)gmail.com>
>  *Sent:* Sunday, July 25, 2010 9:45 PM
>  *To:* ReactOS Development List <ros-dev(a)reactos.org>
>  *Subject:* Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch
>  forcmake bringup.
>
>  I also support a reshuffling of the directories, but not in the cmake
>  branch.  Let that be used JUST for getting cmake up and running and if/once
>  that is merged into trunk, then we look into changing the structure.  Best
>  not to complicate one task by adding more to it.
>
>  ------------------------------
>
>  _______________________________________________
>  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
>

[Zachary Gorden]

Do you have any specific proposals, Ged?

[Aleksey Bragin]

Ged's and Timo's ideas are expressed on that wiki page he linked earlier:
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.

WBR,
Aleksey Bragin.

From: Zachary Gorden 
Sent: Monday, July 26, 2010 5:16 AM
To: ReactOS Development List 
Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmakebringup.


Do you have any specific proposals, Ged?



--------------------------------------------------------------------------------


_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Andrew Faulds]

Is there some sort of restriction in rbuild regarding the locations of files
in a module? Are source code files restricted to a directory?

On 26 July 2010 09:11, Aleksey Bragin <aleksey(a)reactos.org> wrote:

>    Ged's and Timo's ideas are expressed on that
> wiki page he linked earlier:
>  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.
>
>  WBR,
>  Aleksey Bragin.
>   *From:* Zachary Gorden <drakekaizer666(a)gmail.com>
>  *Sent:* Monday, July 26, 2010 5:16 AM
>  *To:* ReactOS Development List <ros-dev(a)reactos.org>
>  *Subject:* Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch
>  forcmakebringup.
>
>  Do you have any specific proposals, 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
>  


-- 
Andrew Faulds (AJF)
http://ajf.me/

[Timo Kreuzer]

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

[Aleksey Bragin]

--------------------------------------------------
From: "Timo Kreuzer" <timo.kreuzer(a)web.de>
Sent: Tuesday, July 27, 2010 12:11 AM
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Subject: [ros-dev] Tree restructure (was: Re: [ros-diffs] [akhaldi] 48236: 
Create a branch	forcmakebringup.)

>   Aleksey Bragin schrieb:
> >   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. 
>  No, you seem to misunderstand the
> points of the restructure. 
Actually I do, that's what I mean:

>   First: Rbuild sucks and noone is fixing it.
Yes.

>   It's also not the responsibility of the build
> system to handle the
>  development process or compensate for a broken file layout. 
I'm not really
discussing pros or cons of the proposed layout (which I do 
want to discuss - but later), what I really dislike is a statement about 
"build system sucks, noone is fixing it, so let's change layout instead of 
fixing it".

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


WBR,
Aleksey Bragin.

[Ged Murphy]

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.

[Aleksey Bragin]

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

[Timo Kreuzer]

Aleksey Bragin wrote:
>   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,/ 
This is a valid point. One of the few to take care of.

>   make modules harder to find, 
It will actually
make modules much easier to find. When I look for a
module I usually know what kind of module it is. When I look for gdi32,
I know it's a core win32 thing and I don't have to look through hundreds
of wine dlls, just to find gdi32. If I don't know what kind of module
that is, I should either stay away from it, or simply use doxygen, that
will tell me where it is. But this should be really the exception.

>   whatever else, BESIDES hacking around a broken build
> system which
>  can't have proper grouping? 
Did I write in chineese letters on greek
background? How can the build
system care for shorter build times if we always do a clean rebuild of
*everything*? It can't. How can a different file layout do that? Easy:
the buildbot can decide what part of reactos was commited to and only
clean and rebuild THAT part. If I commit some audio file, just rebuild
the audio part. The rest of the tree is unaffected. We also don't
recompile gcc when someone commited to the kernel. The only dependency
that all stuff shares is the "SDK", containing the core headers and core
libs like crt.
This way we could divide our buildbot's build time probably by 5 to 10.
Now please tell me how rbuild or cmake or sysgen can do that?
Another thing is dependencies. Currently everyone just adds dependencies
wherever he likes. There's so much interdependency you can't just not
build something like dlls. For the amd64 port, I added a bunch of hacks
to only compile kernel mode stuff to save a lot of compilation time, but
that took me quite some time to get it working and it's pretty hacky.
The new file layout would allow to simply "comment out" one directory
from the root folder and still everything would build.

>   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. 
The only thing on the
other side of the argumentation that I heard so
far is, that it doesn't matter how bad our file layout is, we can work
around it with a complex build system. But that's not true.

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

[Timo Kreuzer]

Now this is a story all about how somebody's life
got flip turned upside-down. I'd like to take a
minute, just sit right there. I'll tell you about some
guy called Adam Bow

Adam lives in a nice 5 room appartment and he has a very strict tidyness:
- In the 1st room he keeps everything that is made from metal
- In the 2nd room he keeps everything that imade from plastic
- In the 3rd room he keeps everything that is made from glass
- In the 4th room he keeps everything organic
- In the 5th room he keeps all electronics

Now one day when he starts to make his meal, he goes into the 1st room
to get a pot, into the 2nd room to get some bowl, in the 3rd room to get
a bottle of vinegar, in the 4th room to get potatoes, in the 5th room to
put the pot on the oven, ... he runs through all his rooms over and over
again. That annoys him so much that he thinks about a solution.
After 3 days constantly thinking, he has the solution: he installs a
railway going through all of his 5 rooms, so he can just sit on a wagon
and drive through his house.

[Zachary Gorden]

Just a reminder to all involved in this discussion, the work with cmake has
one goal, which is to remove our dependency on rbuild and the maintenance
load that using it entails.  rbuild has a lot of issues by itself,
irrespective of the problems it causes in combination with the directory
hierarchy, but trying to go to cmake isn't designed to solve those problems,
just the ones rbuild itself causes.  It may ultimately make solving the
combined issues easier, but that's a secondary, albeit important,
consideration.  That restructuring of the directories will likely be
necessary has very little to do with the cmake effort itself.  So let's not
conflate the two issues.

[Ged Murphy]

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?

 

So you want more reasons?

Instead of focusing on the build, which is where most of our arguments have
lay so far, I'll discuss the merits from a tree structure perspective:

 

Firstly, I don't agree with the 'easier to find' statement. This may be true
for someone with no knowledge of NT, but reactos devs are supposed to know
this stuff.

If the 'easier to find' statement was valid, then I think Timo's suggestion
of laying everything out alphabetically would be better still.

 

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

 

You have to look to the future. Let's consider how Microsoft will do things.


Do you think the Windows source code is dumped into one big TFS database
with everything filed under module type?

This would mean Joe on the kernel team would be effected by what Sam in the
audio department is doing. Changes made by Steve on the COM team might force
a rebuild of what Ian is working on in the shell team.

You can't expect everyone to have a separate branch of the entire source
code to avoid this problem. The code is modularized and people are given
access to the areas which they work on.

 

Imagine if Linux wasn't modularized and changes made to X or Gnome forced
rebuilds of the kernel. It would be carnage. 

 

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.

-          Student devs could be given access to the applications directory.

-          We could build up an ntcore directory, make it bootable (aka
minwin) and kernel devs could be given branches to this area without the
noise of a full OS.

-          Graphics guys could be checkout the build tools, an ntcore and a
win32core areas. They could have write access to win32core and work on that
without worrying about what the student devs are doing in the apps dir.

 

 

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.

 

Ged.

 

 

 

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] 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 <mailto:[e-mail]>  Murphy 

Sent: Tuesday, July 27, 2010 1:23 AM

To: ReactOS <mailto:[e-mail]>  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 &lt;aleksey(a)reactos.org&gt; 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

[Aleksey Bragin]

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:[e-mail]] 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

[Ged Murphy]

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.

>   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 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:[e-mail]] 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

[Jérôme Gardou]

> >   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.
>
>      
Isn't it possible to do hard links with svn, git or whatever?

So as in your example, mmsys.cpl would be located in the audio sub tree, 
and hardlinked to the UI/cpl directory.

All modern filesystems support hard links, that wouldn't suprise me if 
modern version control systems would do the same.

What do you think?

[Jérôme Gardou]

And here is what I said.
http://svnbook.red-bean.com/en/1.0/ch07s03.html

Jérôme Gardou wrote:
>  
>
> > >   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.
> >  
>  Isn't it possible to do hard links with svn, git or whatever?
>
>  So as in your example, mmsys.cpl would be located in the audio sub 
>  tree, and hardlinked to the UI/cpl directory.
>
>  All modern filesystems support hard links, that wouldn't suprise me if 
>  modern version control systems would do the same.
>
>  What do you think?
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Aleksey Bragin]

Sorry, for some reason Windows Mail screwed up when I was answering between 
the lines in your email. ( That's why I like MacOS X's mail client :) )

Thanks for reposting with quotation marks.

WBR,
Aleksey..

--------------------------------------------------
From: "Ged Murphy" <gedmurphy(a)gmail.com>
Sent: Wednesday, July 28, 2010 6:45 PM
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Tree restructure (was:Re:[ros-diffs]	[akhaldi]48236:Createa branch
forcmakebringup.)

>   That made for hard reading.
>  I've split my original points up so anyone following this can understand 
>  it.

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

[Andrew Faulds]

>   > > 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. 
I
can't see how hard that would be to do.
Build ROS, do a search for .cpl files in output-i386, make a note of
their paths then find their equivalent source files.

Andrew Faulds
http://ajf.me/

[Adam Kachwalla]

I might be a bit of a n00b but at this stage, I also support this  
restructuring of the tree. I also see a potential for optimizing builds to  
allow for building a set of components, as opposed to having to work out  
what components go with what and build them all individually.

Might also help as there are loads of branches in the repository, many   
that haven't been updated in years, that can be easily reduced in size  
and/or merged as a result of the scheme.

That's just my thoughts on it, but I'm not really had more than about 3-4+  
months experience with the ReactOS codebase.

On Mon, 26 Jul 2010 04:46:07 +1000, Ged Murphy <gedmurphy(a)gmail.com> wrote:

>   The logical layout is exactly what is wrong with the
> tree. The tree is  
>  currently laid out in a manner which you would expect someone who  
> >  doesn't understand NT architecture. Things are
> > laid out by type instead   
>  of by architecture.
>  It makes building individual areas of the operating system very  
>  difficult.
>
>  On 25 July 2010 19:03, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> >   Yes, there is no sense in doing two mainly
> > unrelated very big tasks  
> >  simulteneously. Also my own opinion still hasn't changed - existing  
> > >  >layout is quite logical (there are exceptions,
> > > but they are   
> >  everywhere), and any modularization could be achieved already with 
> >
> >  existing >>tools like sysgen.
> > Let cmake branch be actual cmake experiment, not an awesome attempt to  
> >  fix whole ReactOS at onceWBR,
> >  Aleksey Bragin.
> >
> >  From: Zachary GordenSent: Sunday, July 25, 2010 9:45 PM
> >  To: ReactOS Development ListSubject: Re: [ros-dev] [ros-diffs]  
> >  [akhaldi] 48236: Create a branch forcmake bringup.
> >
> >  I also support a reshuffling of the directories, but not in the cmake  
> >  branch.  Let that be used JUST for getting cmake up and running and  
> > >  >if/once that is merged into trunk, then we
> > > look into changing the   
> >  structure.  Best not to complicate one task by adding more
> > to it.
> >
> >  _______________________________________________
> >  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 
>  


-- 
Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish.

[Gabriel ilardi]

I think that the tree reshuffle should be done separately from the cmake branch. I also
agree with Ged that it isn't very logical, so from this point of view I support the
tree restructure.
On the other hand ReactOS is in a really bad shape form a user point of view and all the
resources should focus on fix the most important bugs and regressions listed in
http://www.reactos.org/wiki/Buglist. The rest of the things
is of a minor importance to me. We can't do everything at the same time, we should
focus and things of major importance at the moment.
Just my 2 cents.

Gabriel.

To: ros-dev(a)reactos.org; gedmurphy(a)gmail.com
Date: Fri, 30 Jul 2010 21:05:10 +1000
From: geekdundee(a)gmail.com
Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.






I might be a bit of a n00b but at this stage, I also support this restructuring of the
tree. I also see a potential for optimizing builds to allow for building a set of
components, as opposed to having to work out what components go with what and build them
all individually.
Might also help as there are loads of branches in the repository, many  that haven't
been updated in years, that can be easily reduced in size and/or merged as a result of the
scheme.
That's just my thoughts on it, but I'm not really had more than about 3-4+ months
experience with the ReactOS codebase.
On Mon, 26 Jul 2010 04:46:07 +1000, Ged Murphy <gedmurphy(a)gmail.com> wrote:

The logical layout is exactly what is wrong with the tree. The tree is currently laid out
in a manner which you would expect someone who doesn't understand NT architecture.
Things are laid out by type instead of by architecture.
It makes building individual areas of the operating system very difficult.
On 25 July 2010 19:03, Aleksey Bragin <aleksey(a)reactos.org> wrote:






Yes, there is no sense in doing two 
mainly unrelated very big tasks simulteneously. Also my own opinion still 
hasn't changed - existing layout is quite logical (there are exceptions, but 
they are everywhere), and any modularization could be achieved already with 
existing tools like sysgen.
 
Let cmake branch be actual cmake experiment, not an 
awesome attempt to fix whole ReactOS at once 
 
WBR,
Aleksey Bragin.
 




From: Zachary Gorden 
Sent: Sunday, July 25, 2010 9:45 PM
To: ReactOS Development List 
Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch 
forcmake bringup.

I also support a reshuffling of the directories, but not in the 
cmake branch.  Let that be used JUST for getting cmake up and running and 
if/once that is merged into trunk, then we look into changing the 
structure.  Best not to complicate one task by adding more to it.





_______________________________________________
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





-- Give a man a fish and he will eat for a day.
Teach a man to fish and he will eat for a lifetime.
Give a man religion and he will die praying for a fish. 		 	   		  
_________________________________________________________________
Avatar per Messenger e sfondo per il PC. Creali gratis!
http://www.experience.windows.com/landing2.aspx?culture=it-it

[Jérôme Gardou]

Having a proper build system and a good tree structure is a mandatory 
step to work efficiently. As long as we have neither of them, it is a 
priority.
That's just my opinion, though...

Gabriel ilardi wrote:
>   I think that the tree reshuffle should be done
> separately from the 
>  cmake branch. I also agree with Ged that it isn't very logical, so 
>  from this point of view I support the tree restructure.
>  On the other hand ReactOS is in a really bad shape form a user point 
>  of view and all the resources should focus on fix the most important 
>  bugs and regressions listed in http://www.reactos.org/wiki/Buglist. 
>  The rest of the things
>  is of a minor importance to me. We can't do everything at the same 
>  time, we should focus and things of major importance at the moment.
>  Just my 2 cents.
>
>  Gabriel.
>

[victor martinez]

Answers inlined.

 
>   Having a proper build system and a good tree structure
> is a mandatory 
>  step to work efficiently. As long as we have neither of them, it is a 
>  priority.
>  That's just my opinion, though... 
 

In my opinion there are more mandatory things:




1) Avoiding to commit partial code. For partial code or partial-semi-working features you
can use branchs.
2) Just tested code commited to trunk. You can make (ab)use of testers or try in your own.
We have regressed a lot after the big bug hunting.
3) Freezing trunk until the current code is stable enough. In the same way Windows
invented the word "Downgrade" with Vista we have invented the
"RegressOS" word.
4) And then, after we have "something" we can improve the
"something".
5) And after that we can talk about changing to Git, using CMAKE,and restructuring a Tree,
or a Forest.


I am not saying a restructure is needed, or moving to CMAKE is a bad thing. But we have
better things to be done.


>   > On the other hand ReactOS is in a really bad
> shape form a user point 
>  > of view and all the resources should focus on fix the most important 
>  > bugs and regressions listed in http://www.reactos.org/wiki/Buglist. 
>  > The rest of the things
>  > is of a minor importance to me. We can't do everything at the same 
>  > time, we should focus and things of major importance at the moment.
>  > Just my 2 cents. 
Full agree. +1000000.

Freezing Trunk asap or a serious movement to fix the regressions (reverts allowed).

[Andrew Faulds]

On 30 July 2010 22:44, victor martinez <vicmarcal(a)hotmail.com> wrote:
> >   > On the
> > other hand ReactOS is in a really bad shape form a user point
> >  > of view and all the resources should focus on fix the most important
> >  > bugs and regressions listed in http://www.reactos.org/wiki/Buglist.
> >  > The rest of the things
> >  > is of a minor importance to me. We can't do everything at the same
> >  > time, we should focus and things of major importance at the moment.
> >  > Just my 2 cents. 
>  Full agree. +1000000.
>
>  Freezing Trunk asap or a serious movement to fix the regressions (reverts allowed).
We need this, else it may be another millennia until 0.3.12...
--
Andrew Faulds (AJF)
http://ajf.me/

[Bernd Blaauw]

  Op 30-7-2010 23:52, Andrew Faulds schreef:
>   We need this, else it may be another millennia until
> 0.3.12...
>  -- 
Nothing wrong with celebrating (likely soon upcoming) commit 50.000 by 
releasing it as 0.3.12 or so ^^.

[Ged Murphy]

On 30 July 2010 22:44, victor martinez <vicmarcal(a)hotmail.com> wrote:
>  
>
>
>  In my opinion there are more mandatory things:
>
>
>
>
>  1) Avoiding to commit partial code. For partial code or
>  partial-semi-working features you can use branchs.
>  2) Just tested code commited to trunk. You can make (ab)use of testers or
>  try in your own. We have regressed a lot after the big bug hunting.
>  3) Freezing trunk until the current code is stable enough. In the same way
>  Windows invented the word "Downgrade" with Vista we have invented the
>  "RegressOS" word.
>  4) And then, after we have "something" we can improve the
> "something".
>  5) And after that we can talk about changing to Git, using CMAKE,and
>  restructuring a Tree, or a Forest.
>
>
>  I am not saying a restructure is needed, or moving to CMAKE is a bad thing.
>  But we have better things to be done.
>  

Although valid, I don't think any of your points have anything to do with a
tree restructure.
Maybe you misunderstand the reasoning behind the proposed architecture and
what it can do to help us?

Anyone who is unsure should speak with Timo or maybe lassy in IRC and they
can better help to explain it from a development perspective.

Ged.