rosapps

[Dmitry Chapyshev]

Hi.

I suggest to divide rosapps on two parts:

1) Components which are present in Windows (rosapps)
2) 3rd party components (3rdapps)

In rosapps it is necessary to place all components without which the  
system can normally work (calc, hh, winhlp32, charmap, games and etc)

In 3rdapps components which are not present in Windows (downloader,  
imagesoft and etc) will take places

Such placing of components will allow to reduce compilation time as you  
can not compile not the modules necessary to you (rosapps and/or 3rdapps)

Please tell your opinion on my proposition.

-- 
WBR,
Dmitry Chapyshev

[Zachary Gorden]

Huh?  The rosapps module isn't included by default in the build to begin
with, so how does it decrease build time?  Also, the applications in there
are supposed to be providing equivalent functionality found in Windows.
Downloader is an exception, but what else is?

On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru> wrote:

>   Hi.
>
>  I suggest to divide rosapps on two parts:
>
>  1) Components which are present in Windows (rosapps)
>  2) 3rd party components (3rdapps)
>
>  In rosapps it is necessary to place all components without which the
>  system can normally work (calc, hh, winhlp32, charmap, games and etc)
>
>  In 3rdapps components which are not present in Windows (downloader,
>  imagesoft and etc) will take places
>
>  Such placing of components will allow to reduce compilation time as you
>  can not compile not the modules necessary to you (rosapps and/or 3rdapps)
>
>  Please tell your opinion on my proposition.
>
>  --
>  WBR,
>  Dmitry Chapyshev
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Dmitry Chapyshev]

The majority of programs in rosapps NOT "to be providing equivalent  
functionality found in Windows". It is possible to carry To such programs  
only fontview, magnify and winver.

It is necessary to make the separate module for programs which have  
analogues in Windows and 3rd party components. Thus, we will have an  
opportunity to compile not all programs in rosapps, but only the  
necessary. As in rosapps it is possible to transfer calc, hh, winhlp32,  
charmap, games, etc. It will allow not to compile each time these  
components if in them there is no necessity.

I think, that Fireball will comment on my proposition, I am possible have  
not clearly enough explained an essence.

On Sun, 08 Mar 2009 19:02:25 +0300, Zachary Gorden  
<drakekaizer666(a)gmail.com> wrote:

>   Huh?  The rosapps module isn't included by default
> in the build to begin  
>  with, so how does it decrease build time?  Also, the applications in  
>  there are supposed to be providing equivalent functionality found in  
>  Windows.  Downloader is an exception, but what else is? 


-- 
WBR,
Dmitry Chapyshev

[Aleksey Bragin]

I'll explain his idea.

The idea he would likes to propose is to separate the mess inside  
rosapps, and provide a clear division of what goes where:
1. trunk/reactos contains ONLY stuff which is vital for the system to  
work minimally. Including explorer, GUI, and things like that, but  
without calculator, solitaire, or anything like that.
2. rosapps - components similar to those present in Windows, but not  
vital for the boot process.
3. addons - components, which are additional to the base set of apps  
and drivers Windows ships with.

Comments are welcome on his idea.

My own comment is that the idea seems to recall what we originally  
been discussing a year or more ago, but stopped caring as more devs  
got more powerful PCs. There is no strict solution on what goes where  
now, actually that's why his idea started - he proposed to move  
winver and winhlp back to trunk, and I was arguing over it.


WBR,
Aleksey Bragin.


On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:

>   Huh?  The rosapps module isn't included by default
> in the build to  
>  begin with, so how does it decrease build time?  Also, the  
>  applications in there are supposed to be providing equivalent  
>  functionality found in Windows.  Downloader is an exception, but  
>  what else is?
>
>  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev  
>  <lentind(a)yandex.ru> wrote:
>  Hi.
>
>  I suggest to divide rosapps on two parts:
>
>  1) Components which are present in Windows (rosapps)
>  2) 3rd party components (3rdapps)
>
>  In rosapps it is necessary to place all components without which the
>  system can normally work (calc, hh, winhlp32, charmap, games and etc)
>
>  In 3rdapps components which are not present in Windows (downloader,
>  imagesoft and etc) will take places
>
>  Such placing of components will allow to reduce compilation time as  
>  you
>  can not compile not the modules necessary to you (rosapps and/or  
>  3rdapps)
>
>  Please tell your opinion on my proposition.
>
>  --
>  WBR,
>  Dmitry Chapyshev
>  _______________________________________________
>  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]

I would opt for deleting everything in rosapps.

I'm not really sure why it's important to start rearranging it as there's
very little of use in there.

 

As per our project mandate we aren't interested in anything which isn't
core.

 

Ged.

 

 

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Aleksey Bragin
Sent: 08 March 2009 18:16
To: ReactOS Development List
Subject: Re: [ros-dev] rosapps

 

I'll explain his idea.

 

The idea he would likes to propose is to separate the mess inside rosapps,
and provide a clear division of what goes where:

1. trunk/reactos contains ONLY stuff which is vital for the system to work
minimally. Including explorer, GUI, and things like that, but without
calculator, solitaire, or anything like that.

2. rosapps - components similar to those present in Windows, but not vital
for the boot process.

3. addons - components, which are additional to the base set of apps and
drivers Windows ships with.

 

Comments are welcome on his idea.

 

My own comment is that the idea seems to recall what we originally been
discussing a year or more ago, but stopped caring as more devs got more
powerful PCs. There is no strict solution on what goes where now, actually
that's why his idea started - he proposed to move winver and winhlp back to
trunk, and I was arguing over it.

 

 

WBR,

Aleksey Bragin.

 

 

On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:





Huh?  The rosapps module isn't included by default in the build to begin
with, so how does it decrease build time?  Also, the applications in there
are supposed to be providing equivalent functionality found in Windows.
Downloader is an exception, but what else is?

On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru> wrote:

Hi.

I suggest to divide rosapps on two parts:

1) Components which are present in Windows (rosapps)
2) 3rd party components (3rdapps)

In rosapps it is necessary to place all components without which the
system can normally work (calc, hh, winhlp32, charmap, games and etc)

In 3rdapps components which are not present in Windows (downloader,
imagesoft and etc) will take places

Such placing of components will allow to reduce compilation time as you
can not compile not the modules necessary to you (rosapps and/or 3rdapps)

Please tell your opinion on my proposition.

--
WBR,
Dmitry Chapyshev
_______________________________________________
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

[Aleksey Bragin]

So, are there any objections in separating thirdparty, additional,  
sometimes helpful stuff into addons module, and having all apps which  
exist in Windows, but aren't required for booting into rosapps?

Please, let's come to a solution, because having such a trash can  
which rosapps is now is unbearable.


WBR,
Aleksey Bragin.

On Mar 9, 2009, at 2:50 AM, Ged wrote:

>   I would opt for deleting everything in rosapps.
>
>  I’m not really sure why it’s important to start rearranging it as  
>  there’s very little of use in there.
>
>
>
>  As per our project mandate we aren’t interested in anything which  
>  isn’t core.
>
>
>
>  Ged.
>
>
>
>
>
>  From: ros-dev-bounces(a)reactos.org [mailto:ros-dev- 
>  bounces(a)reactos.org] On Behalf Of Aleksey Bragin
>  Sent: 08 March 2009 18:16
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] rosapps
>
>
>
>  I'll explain his idea.
>
>
>
>  The idea he would likes to propose is to separate the mess inside  
>  rosapps, and provide a clear division of what goes where:
>
>  1. trunk/reactos contains ONLY stuff which is vital for the system  
>  to work minimally. Including explorer, GUI, and things like that,  
>  but without calculator, solitaire, or anything like that.
>
>  2. rosapps - components similar to those present in Windows, but  
>  not vital for the boot process.
>
>  3. addons - components, which are additional to the base set of  
>  apps and drivers Windows ships with.
>
>
>
>  Comments are welcome on his idea.
>
>
>
>  My own comment is that the idea seems to recall what we originally  
>  been discussing a year or more ago, but stopped caring as more devs  
>  got more powerful PCs. There is no strict solution on what goes  
>  where now, actually that's why his idea started - he proposed to  
>  move winver and winhlp back to trunk, and I was arguing over it.
>
>
>
>
>
>  WBR,
>
>  Aleksey Bragin.
>
>
>
>
>
>  On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
>
>
>
>
>  Huh?  The rosapps module isn't included by default in the build to  
>  begin with, so how does it decrease build time?  Also, the  
>  applications in there are supposed to be providing equivalent  
>  functionality found in Windows.  Downloader is an exception, but  
>  what else is?
>
>  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev  
>  <lentind(a)yandex.ru> wrote:
>
>  Hi.
>
>  I suggest to divide rosapps on two parts:
>
>  1) Components which are present in Windows (rosapps)
>  2) 3rd party components (3rdapps)
>
>  In rosapps it is necessary to place all components without which the
>  system can normally work (calc, hh, winhlp32, charmap, games and etc)
>
>  In 3rdapps components which are not present in Windows (downloader,
>  imagesoft and etc) will take places
>
>  Such placing of components will allow to reduce compilation time as  
>  you
>  can not compile not the modules necessary to you (rosapps and/or  
>  3rdapps)
>
>  Please tell your opinion on my proposition.
>

[Komarov Alexey]

I think, that detachment of stuff which is vital for the system to work 
minimally will lead to reduce compilation time on the one hand, but also 
will lead:
1. Reduction quantity of tests for the components removed from 
trunk/reactos. That's bad for that components.
2. Components similar to those present in Windows, but not vital for the 
boot process, allow to test other parts ReactOS, revealing errors in 
shell32, kernel etc.

I against to remove such components from trunk/reactos, but I'm not 
developer. You decide.

q4a.
>   So, are there any objections in separating thirdparty,
> additional, 
>  sometimes helpful stuff into addons module, and having all apps which 
>  exist in Windows, but aren't required for booting into rosapps?
>
>  Please, let's come to a solution, because having such a trash can 
>  which rosapps is now is unbearable.
>
>
>  WBR,
>  Aleksey Bragin.
>
>  On Mar 9, 2009, at 2:50 AM, Ged wrote:
>
> > I would opt for deleting everything in rosapps.
> >
> > I’m not really sure why it’s important to start rearranging it as 
> > there’s very little of use in there.
> >
> >  
> >
> > As per our project mandate we aren’t interested in anything which 
> > isn’t core.
> >
> >  
> >
> > Ged.
> >
> >  
> >
> >  
> >
> > *From:* ros-dev-bounces(a)reactos.org 
> > [mailto:[e-mail]] *On Behalf Of *Aleksey Bragin
> > *Sent:* 08 March 2009 18:16
> > *To:* ReactOS Development List
> > *Subject:* Re: [ros-dev] rosapps
> >
> >  
> >
> > I'll explain his idea.
> >
> >  
> >
> > The idea he would likes to propose is to separate the mess inside 
> > rosapps, and provide a clear division of what goes where:
> >
> > 1. trunk/reactos contains ONLY stuff which is vital for the system to 
> > work minimally. Including explorer, GUI, and things like that, but 
> > without calculator, solitaire, or anything like that.
> >
> > 2. rosapps - components similar to those present in Windows, but not 
> > vital for the boot process.
> >
> > 3. addons - components, which are additional to the base set of apps 
> > and drivers Windows ships with.
> >
> >  
> >
> > Comments are welcome on his idea.
> >
> >  
> >
> > My own comment is that the idea seems to recall what we originally 
> > been discussing a year or more ago, but stopped caring as more devs 
> > got more powerful PCs. There is no strict solution on what goes where 
> > now, actually that's why his idea started - he proposed to move 
> > winver and winhlp back to trunk, and I was arguing over it.
> >
> >  
> >
> >  
> >
> > WBR,
> >
> > Aleksey Bragin.
> >
> >  
> >
> >  
> >
> > On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
> >
> >
> >
> > Huh?  The rosapps module isn't included by default in the build to 
> > begin with, so how does it decrease build time?  Also, the 
> > applications in there are supposed to be providing equivalent 
> > functionality found in Windows.  Downloader is an exception, but what 
> > else is?
> >
> > On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru 
> > <mailto:[e-mail]>> wrote:
> >
> > Hi.
> >
> > I suggest to divide rosapps on two parts:
> >
> > 1) Components which are present in Windows (rosapps)
> > 2) 3rd party components (3rdapps)
> >
> > In rosapps it is necessary to place all components without which the
> > system can normally work (calc, hh, winhlp32, charmap, games and etc)
> >
> > In 3rdapps components which are not present in Windows (downloader,
> > imagesoft and etc) will take places
> >
> > Such placing of components will allow to reduce compilation time as you
> > can not compile not the modules necessary to you (rosapps and/or 3rdapps)
> >
> > Please tell your opinion on my proposition.
> >

[Dmitry Gorbachev]

>   1. Reduction quantity of tests for the components
> removed from
>  trunk/reactos. That's bad for that components.
>  2. Components similar to those present in Windows, but not vital for the
>  boot process, allow to test other parts ReactOS, revealing errors in
>  shell32, kernel etc. 
These components can be included on CD images. People who build from
sources will decide themselves, whether they want to compile this
stuff.

[Steven Edwards]

2009/3/12 Aleksey Bragin <aleksey(a)reactos.org>rg>:
>   So, are there any objections in separating thirdparty,
> additional, sometimes
>  helpful stuff into addons module, and having all apps which exist in
>  Windows, but aren't required for booting into rosapps?
>  Please, let's come to a solution, because having such a trash can which
>  rosapps is now is unbearable. 
Good riddance but I would go a step further. What are you planning on
leaving in reactos and what are you planning on moving to rosapps?
Without a clear outline I think its risky to say 'sure split it as you
desire'. The current tree layout represents a lot of work and design
Alex did long ago and I am hesitant to see it divested without a wiki
page explaining what is going where.

I mean if your going to strip it down to only the applications
required for booting then I think you should move all non essential
services over as well. My thinking is something more radically
different along the lines of the attached screenshot. But my question
is, what does it gain? Without a change in behavior, your just moving
the problem around.

My thinking is that we are never going to get around the
interdependancy mess with the sdk/ddk/ndk/wine/w32api. However, we can
make it a requirement that we limit commits that affect across
submodules to window. Perhaps changes from each module have to be
merged one day a week or something. This way developer joe does not
commit Wine code and SDK changes on tuesday that force developer fred
to update and rebuild the entire ReactOS tree to merge. Likewise
perhaps rbuild changes can only be merged on Sundays so we've got the
whole week to deal with them.

Hear me out on this. Something like

1. Changes to base,user, services, whatever that does not affect
another module can go in the tree 24x7

2. Wine dlls updates that affect sdk/ddk/ndk follow sdk rules, Simple
Wine updates not requiring IDL changes can go in any time as in rule
1.

3. WineSDK, third party libs, sdk/ddk/ndk,rbuild and rosbe changes get
merged on the weekends

So my thoughts are a little rough around the edges but you get the
idea. The hope is we make the tree pretty granular and we know ahead
of time when major breakages are going to happen. I suspect others
have ideas too. I think before we go moving anything we need to wikify
the plan as Alex did last time we had a major tree restructuring
because it served us very well.

There is nothing wrong with having a window for merges, with modern
revision control, everyone is free to have a branch that is their own
private playground and it just makes sense for the stability of
everyone to limit the times at which we merge. If we are not going to
do this, then changing the layout seems pretty pointless to me.

Thanks

P.S. I just remembered, I left a test/kernel test/winetest module off
the list. It is imperative that we make it to where any commits+merges
that result in a test failure be rejected. non-trunk commits/merges
could be free to fail all day long.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Zachary Gorden]

Not an objection per se, but if we're going to be pulling stuff out, then
I'd prefer to have the buildbot build all that stuff in by default.  The
bandwidth argument is seriously running on thin ice these days, and if we do
pull that much stuff out, it's going to be even more of a hassle to set up
the system to a "usable" state, not just a booting one.

[Aleksey Bragin]

Noone proposed to change tree layout, I like it a lot. And it should  
be kept intact.

The question is - do we want to separate non-essential apps into a  
standalone module, and separate additional, not present in Windows  
apps into yet another module?

Or get rid of almost everything in rosapps, and merge what's left  
into trunk?

On Mar 12, 2009, at 4:34 PM, Steven Edwards wrote:

>   2009/3/12 Aleksey Bragin <aleksey(a)reactos.org>rg>:
> >   So, are there any objections in separating
> > thirdparty, additional,  
> >  sometimes
> >  helpful stuff into addons module, and having all apps which exist in
> >  Windows, but aren't required for booting into rosapps?
> >  Please, let's come to a solution, because having such a trash can  
> >  which
> >  rosapps is now is unbearable. 
>  Good riddance but I would go a step further. What are you planning on
>  leaving in reactos and what are you planning on moving to rosapps?
>  Without a clear outline I think its risky to say 'sure split it as you
>  desire'. The current tree layout represents a lot of work and design
>  Alex did long ago and I am hesitant to see it divested without a wiki
>  page explaining what is going where.
>
>  I mean if your going to strip it down to only the applications
>  required for booting then I think you should move all non essential
>  services over as well. My thinking is something more radically
>  different along the lines of the attached screenshot. But my question
>  is, what does it gain? Without a change in behavior, your just moving
>  the problem around.
>
>  My thinking is that we are never going to get around the
>  interdependancy mess with the sdk/ddk/ndk/wine/w32api. However, we can
>  make it a requirement that we limit commits that affect across
>  submodules to window. Perhaps changes from each module have to be
>  merged one day a week or something. This way developer joe does not
>  commit Wine code and SDK changes on tuesday that force developer fred
>  to update and rebuild the entire ReactOS tree to merge. Likewise
>  perhaps rbuild changes can only be merged on Sundays so we've got the
>  whole week to deal with them.
>
>  Hear me out on this. Something like
>
>  1. Changes to base,user, services, whatever that does not affect
>  another module can go in the tree 24x7
>
>  2. Wine dlls updates that affect sdk/ddk/ndk follow sdk rules, Simple
>  Wine updates not requiring IDL changes can go in any time as in rule
>  1.
>
>  3. WineSDK, third party libs, sdk/ddk/ndk,rbuild and rosbe changes get
>  merged on the weekends
>
>  So my thoughts are a little rough around the edges but you get the
>  idea. The hope is we make the tree pretty granular and we know ahead
>  of time when major breakages are going to happen. I suspect others
>  have ideas too. I think before we go moving anything we need to wikify
>  the plan as Alex did last time we had a major tree restructuring
>  because it served us very well.
>
>  There is nothing wrong with having a window for merges, with modern
>  revision control, everyone is free to have a branch that is their own
>  private playground and it just makes sense for the stability of
>  everyone to limit the times at which we merge. If we are not going to
>  do this, then changing the layout seems pretty pointless to me.
>
>  Thanks
>
>  P.S. I just remembered, I left a test/kernel test/winetest module off
>  the list. It is imperative that we make it to where any commits+merges
>  that result in a test failure be rejected. non-trunk commits/merges
>  could be free to fail all day long.
>
>  -- 
>  Steven Edwards

[Steven Edwards]

On Thu, Mar 12, 2009 at 10:16 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
>   Or get rid of almost everything in rosapps, and merge
> what's left
>  into trunk? 
If its important then I guess it should go in to trunk. I like having
a scratch area where developers can upload new things without sticking
them in trunk or having to create a branch but I agree rosapps does
not seem to be the place. Say we kill rosapps, could we get something
like a playground module where its understood, things can go here for
a while, break, bitrot, whatever. I point to my recent work on telnetd
as a reason why its handy. I didn't want to merge it to trunk until
its more feature complete, but its not worth having its own branch.
Now that its mostly working on windows, I am ok with it going in to
reactos proper.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo

[Thomas Bluemel]

Instead of actually removing this stuff from trunk, can't we drive this 
by an environment variable with rbuild so that it skips building modules 
not neccessary?

Thomas
Aleksey Bragin wrote:
>   So, are there any objections in separating thirdparty,
> additional, 
>  sometimes helpful stuff into addons module, and having all apps which 
>  exist in Windows, but aren't required for booting into rosapps?
>  
>  Please, let's come to a solution, because having such a trash can which 
>  rosapps is now is unbearable.
>  
>  
>  WBR,
>  Aleksey Bragin.
>  
>  On Mar 9, 2009, at 2:50 AM, Ged wrote:
>  
> >   I would opt for deleting everything in rosapps.
> >
> >  I’m not really sure why it’s important to start rearranging it as 
> >  there’s very little of use in there.
> >
> >   
> >
> >  As per our project mandate we aren’t interested in anything which 
> >  isn’t core.
> >
> >   
> >
> >  Ged.
> >
> >   
> >
> >   
> >
> >  *From:* ros-dev-bounces(a)reactos.org 
> >  [mailto:[e-mail]] *On Behalf Of *Aleksey Bragin
> >  *Sent:* 08 March 2009 18:16
> >  *To:* ReactOS Development List
> >  *Subject:* Re: [ros-dev] rosapps
> >
> >   
> >
> >  I'll explain his idea.
> >
> >   
> >
> >  The idea he would likes to propose is to separate the mess inside 
> >  rosapps, and provide a clear division of what goes where:
> >
> >  1. trunk/reactos contains ONLY stuff which is vital for the system to 
> >  work minimally. Including explorer, GUI, and things like that, but 
> >  without calculator, solitaire, or anything like that.
> >
> >  2. rosapps - components similar to those present in Windows, but not 
> >  vital for the boot process.
> >
> >  3. addons - components, which are additional to the base set of apps 
> >  and drivers Windows ships with.
> >
> >   
> >
> >  Comments are welcome on his idea.
> >
> >   
> >
> >  My own comment is that the idea seems to recall what we originally 
> >  been discussing a year or more ago, but stopped caring as more devs 
> >  got more powerful PCs. There is no strict solution on what goes where 
> >  now, actually that's why his idea started - he proposed to move winver 
> >  and winhlp back to trunk, and I was arguing over it.
> >
> >   
> >
> >   
> >
> >  WBR,
> >
> >  Aleksey Bragin.
> >
> >   
> >
> >   
> >
> >  On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
> >
> >
> >
> >  Huh?  The rosapps module isn't included by default in the build to 
> >  begin with, so how does it decrease build time?  Also, the 
> >  applications in there are supposed to be providing equivalent 
> >  functionality found in Windows.  Downloader is an exception, but what 
> >  else is?
> >
> >  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru 
> >  <mailto:[e-mail]>> wrote:
> >
> >  Hi.
> >
> >  I suggest to divide rosapps on two parts:
> >
> >  1) Components which are present in Windows (rosapps)
> >  2) 3rd party components (3rdapps)
> >
> >  In rosapps it is necessary to place all components without which the
> >  system can normally work (calc, hh, winhlp32, charmap, games and etc)
> >
> >  In 3rdapps components which are not present in Windows (downloader,
> >  imagesoft and etc) will take places
> >
> >  Such placing of components will allow to reduce compilation time as you
> >  can not compile not the modules necessary to you (rosapps and/or 3rdapps)
> >
> >  Please tell your opinion on my proposition.
> >  
>  
>  
>  ------------------------------------------------------------------------
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ged]

I prefer this idea.

I'd like to see rosapps removed completely and have all non essential stuff
in trunk built via an rbuild variable (turned off by default)

Ged.


-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Thomas Bluemel
Sent: 12 March 2009 14:17
To: ReactOS Development List
Subject: Re: [ros-dev] rosapps

Instead of actually removing this stuff from trunk, can't we drive this 
by an environment variable with rbuild so that it skips building modules 
not neccessary?

Thomas
Aleksey Bragin wrote:
>   So, are there any objections in separating thirdparty,
> additional, 
>  sometimes helpful stuff into addons module, and having all apps which 
>  exist in Windows, but aren't required for booting into rosapps?
>  
>  Please, let's come to a solution, because having such a trash can which 
>  rosapps is now is unbearable.
>  
>  
>  WBR,
>  Aleksey Bragin.
>  
>  On Mar 9, 2009, at 2:50 AM, Ged wrote:
>  
> >   I would opt for deleting everything in rosapps.
> >
> >  I'm not really sure why it's important to start rearranging it as 
> >  there's very little of use in there.
> >
> >   
> >
> >  As per our project mandate we aren't interested in anything which 
> >  isn't core.
> >
> >   
> >
> >  Ged.
> >
> >   
> >
> >   
> >
> >  *From:* ros-dev-bounces(a)reactos.org 
> >  [mailto:[e-mail]] *On Behalf Of *Aleksey Bragin
> >  *Sent:* 08 March 2009 18:16
> >  *To:* ReactOS Development List
> >  *Subject:* Re: [ros-dev] rosapps
> >
> >   
> >
> >  I'll explain his idea.
> >
> >   
> >
> >  The idea he would likes to propose is to separate the mess inside 
> >  rosapps, and provide a clear division of what goes where:
> >
> >  1. trunk/reactos contains ONLY stuff which is vital for the system to 
> >  work minimally. Including explorer, GUI, and things like that, but 
> >  without calculator, solitaire, or anything like that.
> >
> >  2. rosapps - components similar to those present in Windows, but not 
> >  vital for the boot process.
> >
> >  3. addons - components, which are additional to the base set of apps 
> >  and drivers Windows ships with.
> >
> >   
> >
> >  Comments are welcome on his idea.
> >
> >   
> >
> >  My own comment is that the idea seems to recall what we originally 
> >  been discussing a year or more ago, but stopped caring as more devs 
> >  got more powerful PCs. There is no strict solution on what goes where 
> >  now, actually that's why his idea started - he proposed to move winver 
> >  and winhlp back to trunk, and I was arguing over it.
> >
> >   
> >
> >   
> >
> >  WBR,
> >
> >  Aleksey Bragin.
> >
> >   
> >
> >   
> >
> >  On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
> >
> >
> >
> >  Huh?  The rosapps module isn't included by default in the build to 
> >  begin with, so how does it decrease build time?  Also, the 
> >  applications in there are supposed to be providing equivalent 
> >  functionality found in Windows.  Downloader is an exception, but what 
> >  else is?
> >
> >  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru 
> >  <mailto:[e-mail]>> wrote:
> >
> >  Hi.
> >
> >  I suggest to divide rosapps on two parts:
> >
> >  1) Components which are present in Windows (rosapps)
> >  2) 3rd party components (3rdapps)
> >
> >  In rosapps it is necessary to place all components without which the
> >  system can normally work (calc, hh, winhlp32, charmap, games and etc)
> >
> >  In 3rdapps components which are not present in Windows (downloader,
> >  imagesoft and etc) will take places
> >
> >  Such placing of components will allow to reduce compilation time as you
> >  can not compile not the modules necessary to you (rosapps and/or 3rdapps)
> >
> >  Please tell your opinion on my proposition.
> >  
>  
>  
>  ------------------------------------------------------------------------
>  
>  _______________________________________________
>  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

[Timo Kreuzer]

If we continue the clean rebuild method for RosBuild, the only way to
reduce build time is removing stuff from the build.
If we stuff everything in trunk and just switch it off in the config
file it will lead to missing functionality in the iso's.
So I'd rather suggest seperating stuff from trunk, moving it into
rosapps or whatever and then rebuild only the tree where the last commit
went to, while still putting the other stuff into the iso. We should
also avoid compiling trunk on branch commits, a functionality I miss
since a long time.
But we would need to make the modules independ from trunk then. Wich
would finally lead to seperate the import libraries from the modules.
IMO in the long run a much greater seperation is needed. Having multiple
independend trees, each being individually recompiled on a change. (See
my earlier mail or sedwards' mail)

I also don't like the idea of removing everything that is in rosapps.
There's a lot of stuff that shouldn't go to trunk, but still has it's
right to exist somewhere in our sources.

I second the divide into 3 solution.

Timo


Ged schrieb:
>   I prefer this idea.
>
>  I'd like to see rosapps removed completely and have all non essential stuff
>  in trunk built via an rbuild variable (turned off by default)
>
>  Ged.
>
>
>  -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
>  Behalf Of Thomas Bluemel
>  Sent: 12 March 2009 14:17
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] rosapps
>
>  Instead of actually removing this stuff from trunk, can't we drive this 
>  by an environment variable with rbuild so that it skips building modules 
>  not neccessary?
>
>  Thomas
>  Aleksey Bragin wrote:
>    
> >   So, are there any objections in separating
> > thirdparty, additional, 
> >  sometimes helpful stuff into addons module, and having all apps which 
> >  exist in Windows, but aren't required for booting into rosapps?
> >
> >  Please, let's come to a solution, because having such a trash can which 
> >  rosapps is now is unbearable.
> >
> >
> >  WBR,
> >  Aleksey Bragin.
> >
> >  On Mar 9, 2009, at 2:50 AM, Ged wrote:
> >
> >      
> > >   I would opt for deleting everything in rosapps.
> > >
> > >  I'm not really sure why it's important to start rearranging it as 
> > >  there's very little of use in there.
> > >
> > >   
> > >
> > >  As per our project mandate we aren't interested in anything which 
> > >  isn't core.
> > >
> > >   
> > >
> > >  Ged.
> > >
> > >   
> > >
> > >   
> > >
> > >  *From:* ros-dev-bounces(a)reactos.org 
> > >  [mailto:[e-mail]] *On Behalf Of *Aleksey Bragin
> > >  *Sent:* 08 March 2009 18:16
> > >  *To:* ReactOS Development List
> > >  *Subject:* Re: [ros-dev] rosapps
> > >
> > >   
> > >
> > >  I'll explain his idea.
> > >
> > >   
> > >
> > >  The idea he would likes to propose is to separate the mess inside 
> > >  rosapps, and provide a clear division of what goes where:
> > >
> > >  1. trunk/reactos contains ONLY stuff which is vital for the system to 
> > >  work minimally. Including explorer, GUI, and things like that, but 
> > >  without calculator, solitaire, or anything like that.
> > >
> > >  2. rosapps - components similar to those present in Windows, but not 
> > >  vital for the boot process.
> > >
> > >  3. addons - components, which are additional to the base set of apps 
> > >  and drivers Windows ships with.
> > >
> > >   
> > >
> > >  Comments are welcome on his idea.
> > >
> > >   
> > >
> > >  My own comment is that the idea seems to recall what we originally 
> > >  been discussing a year or more ago, but stopped caring as more devs 
> > >  got more powerful PCs. There is no strict solution on what goes where 
> > >  now, actually that's why his idea started - he proposed to move winver 
> > >  and winhlp back to trunk, and I was arguing over it.
> > >
> > >   
> > >
> > >   
> > >
> > >  WBR,
> > >
> > >  Aleksey Bragin.
> > >
> > >   
> > >
> > >   
> > >
> > >  On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
> > >
> > >
> > >
> > >  Huh?  The rosapps module isn't included by default in the build to 
> > >  begin with, so how does it decrease build time?  Also, the 
> > >  applications in there are supposed to be providing equivalent 
> > >  functionality found in Windows.  Downloader is an exception, but what 
> > >  else is?
> > >
> > >  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru 
> > >  <mailto:[e-mail]>> wrote:
> > >
> > >  Hi.
> > >
> > >  I suggest to divide rosapps on two parts:
> > >
> > >  1) Components which are present in Windows (rosapps)
> > >  2) 3rd party components (3rdapps)
> > >
> > >  In rosapps it is necessary to place all components without which the
> > >  system can normally work (calc, hh, winhlp32, charmap, games and etc)
> > >
> > >  In 3rdapps components which are not present in Windows (downloader,
> > >  imagesoft and etc) will take places
> > >
> > >  Such placing of components will allow to reduce compilation time as you
> > >  can not compile not the modules necessary to you (rosapps and/or 3rdapps)
> > >
> > >  Please tell your opinion on my proposition.
> > >
> > >         
> >  ------------------------------------------------------------------------
> >
> >  _______________________________________________
> >  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
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Dmitry Gorbachev]

Timo Kreuzer wrote:
>   We should also avoid compiling trunk on branch
> commits,
>  a functionality I miss since a long time. 
Yes, is there a way to instruct the build server to compile from a
branch? I think it should be, if header file changes will first go
into a separate branch and then will be merged into the trunk from
time to time.

[Aleksey Bragin]

We have chatted with Art a bit on this topic yesterday, and our  
opinion seems to be that trunk/reactos should include all stuff  
included in a default Windows, but with a modification to rbuild to  
allow tags for each module, and later build by tags.

rosapps would stay as a place for additional non-standard components  
for ReactOS.


Any objections to go this way? Or should we have a voting?


WBR,
Aleksey Bragin.


On Mar 13, 2009, at 12:15 AM, Dmitry Gorbachev wrote:

>   Timo Kreuzer wrote:
> >   We should also avoid compiling trunk on branch
> > commits,
> >  a functionality I miss since a long time. 
>  Yes, is there a way to instruct the build server to compile from a
>  branch? I think it should be, if header file changes will first go
>  into a separate branch and then will be merged into the trunk from
>  time to time.

[Colin Finck]

Aleksey Bragin wrote:
>   We have chatted with Art a bit on this topic
> yesterday, and our  
>  opinion seems to be that trunk/reactos should include all stuff  
>  included in a default Windows 
I'm pretty sure, such a rule will sooner or later lead to questions like "I
don't need this app for my testing, so why was it included?" (for example,
if we would add the mspaint clone from forum user gyROS)
Furthermore, there could also be useful stuff from our side, which should
have a right to live in "reactos". This shouldn't be limited to the
components Windows provides.

One of the other suggestions I remember was something like making "reactos"
contain only the very basic stuff to keep compilation times low.


>   but with a modification to rbuild to  
>  allow tags for each module, and later build by tags. 
Please explain this in more details.

A concept called "buildfamilies" was already implemented in the rbuild
branch, but nothing of that stuff was backported so far.
I'm also concerned that we don't have a clear plan on how to proceed with
our buggy rbuild now.. (at least from what I got to know)


>   Or should we have a voting? 
Probably better to finally have an agreement between all devs.

Best regards,

Colin

[KJK::Hyperion]

Colin Finck wrote:
>   I'm also concerned that we don't have a clear
> plan on how to proceed with
>  our buggy rbuild now.. (at least from what I got to know) 
I am the plan. As I have ranted very often in the IRC channel, the major
issue with rbuild is that it's object-oriented, while all build systems,
ever, are declarative/aspect-oriented. Another issue is that rbuild
files can only declare dependencies, not rules, so any new rules/rule
changes require changes to C++ code. In other words, rbuild perversely
is much _less_ capable than the makefile-based build system it replaced.
Therefore, the first step is turning rbuild into a make replacement that
does things in more reliable ways than string-pasting and file-including

[KJK::Hyperion]

Aleksey Bragin wrote:
>   We have chatted with Art a bit on this topic
> yesterday, and our  
>  opinion seems to be that trunk/reactos should include all stuff  
>  included in a default Windows, but with a modification to rbuild to  
>  allow tags for each module, and later build by tags. 
tags are a bad idea. We don't need any more goddamn attributes for
module elements. What you want is collections of modules, or in other
words, makefile targets other than "all". Object-oriented is a terrible,
terrible paradigm for build systems

Make me a list of the build profiles you want supported, and I'll work
on it. I'll make each of you a tuna sandwich too, anything but a new
godforsaken attribute for module elements

[Aleksey Bragin]

On Mar 26, 2009, at 2:02 PM, KJK::Hyperion wrote:

>   Aleksey Bragin wrote:
> >   We have chatted with Art a bit on this topic
> > yesterday, and our
> >  opinion seems to be that trunk/reactos should include all stuff
> >  included in a default Windows, but with a modification to rbuild to
> >  allow tags for each module, and later build by tags. 
>  tags are a bad idea. We don't need any more goddamn attributes for
>  module elements. What you want is collections of modules, or in other
>  words, makefile targets other than "all". Object-oriented is a  
>  terrible,
>  terrible paradigm for build systems
>
>  Make me a list of the build profiles you want supported, and I'll work
>  on it. I'll make each of you a tuna sandwich too, anything but a new
>  godforsaken attribute for module elements 
We can call it another way, but what I mean is "marking" a module as  
belonging to some group, either via a stupid group="blah" attribute,  
or via <group name="blah">...</group>. And it should be easy to turn
 
on/off building of certain groups via some central  
groupstobuild.rbuild file.

[Marc Piulachs]

I implemented a similar feature on my c# rbuild clone and It worked quite 
well.

I had a new module type 'modulegroup' which was basically a list of other 
modules , for example:

	<module name="opengl" type="modulegroup" description="OpenGL
support">
		<requires>core</requires>
		<requires>mesa32</requires>
		<requires>glu32</requires>
		<requires>opengl32</requires>
	</module>

	<module name="core" type="modulegroup" description="Core
OS">
		<requires>framebuf</requires>
		<requires>vbemp</requires>
                                ...
	</module>

In this sample a virtual module "opengl" was created and it was referencing 
"mesa" , "glu32" and "openg32" but at the same time was also
importing all 
modules referenced by "core" which are the 150 modules required to build a 
functional reactos install image.

typing "make opengl" would only build arround 170 modules and create an iso 
image with them inset of building the other 750 modules obviously saving a 
lot of build time.

My implementation was written from scratch and was full functional producing 
a bootable ISO image arround 6 months ago. With a little more work can be 
good replacement for our old , dusty c++ implementation. More information 
about it on my website.

Regards,
/Marc

--------------------------------------------------
From: "Aleksey Bragin" &lt;aleksey(a)reactos.org&gt;
Sent: Friday, March 27, 2009 1:49 PM
To: "ReactOS Development List" &lt;ros-dev(a)reactos.org&gt;
Subject: Re: [ros-dev] rosapps

>   On Mar 26, 2009, at 2:02 PM, KJK::Hyperion wrote:
>
> >   Aleksey Bragin wrote:
> > >   We have chatted with Art a bit on this topic
> > > yesterday, and our
> > >  opinion seems to be that trunk/reactos should include all stuff
> > >  included in a default Windows, but with a modification to rbuild to
> > >  allow tags for each module, and later build by tags. 
> >  tags are a bad idea. We don't need any more goddamn attributes for
> >  module elements. What you want is collections of modules, or in other
> >  words, makefile targets other than "all". Object-oriented is a
> >  terrible,
> >  terrible paradigm for build systems
> >
> >  Make me a list of the build profiles you want supported, and I'll work
> >  on it. I'll make each of you a tuna sandwich too, anything but a new
> >  godforsaken attribute for module elements 
>  We can call it another way, but what I mean is "marking" a module as
>  belonging to some group, either via a stupid group="blah" attribute,
>  or via <group name="blah">...</group>. And it should be easy to
> turn
>  on/off building of certain groups via some central
>  groupstobuild.rbuild file.
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[KJK::Hyperion]

Aleksey Bragin wrote:
>   We can call it another way, but what I mean is
> "marking" a module as  
>  belonging to some group, either via a stupid group="blah" attribute, 
Not this

>   or via <group
> name="blah">...</group>. 
This

[Alex Ionescu]

I have been asking for module groups (and dependency tracking) for ages :)

Best regards,
Alex Ionescu



On Fri, Mar 27, 2009 at 9:28 AM, KJK::Hyperion <hackbunny(a)reactos.org> wrote:
>   Aleksey Bragin wrote:
> >   We can call it another way, but what I mean is
> > "marking" a module as
> >  belonging to some group, either via a stupid group="blah" attribute, 
>  Not this
>
> >   or via <group
> > name="blah">...</group>. 
>  This
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[KJK::Hyperion]

Alex Ionescu wrote:
>   I have been asking for module groups (and dependency
> tracking) for ages :) 
If a developer requests a rbuild feature in the woods and KJK::Hyperion
isn't hearing, does the feature request make noise?

Why don't we mimic the linux Gentoo distribution?

Gentoo uses flags  USE who changes dependencies at build time

from the gentoo's handbook @ 
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part2_ch…:

"2. USE flags

2.a. What are USE flags?

The ideas behind USE flags

When you are installing Gentoo (or any other distribution, or even 
operating system for that matter) you make choices depending on the 
environment you are working with. A setup for a server differs from a 
setup for a workstation. A gaming workstation differs from a 3D 
rendering workstation.

This is not only true for choosing what packages you want to install, 
but also what features a certain package should support. If you don't 
need OpenGL, why would you bother installing OpenGL and build OpenGL 
support in most of your packages? If you don't want to use KDE, why 
would you bother compiling packages with KDE support if those packages 
work flawlessly without?

To help users in deciding what to install/activate and what not, we 
wanted the user to specify his/her environment in an easy way. This 
forces the user into deciding what they really want and eases the 
process for Portage, our package management system, to make useful 
decisions.

Definition of a USE flag

Enter the USE flags. Such a flag is a keyword that embodies support and 
dependency-information for a certain concept. If you define a certain 
USE flag, Portage will know that you want support for the chosen 
keyword. Of course this also alters the dependency information for a 
package.

Let us take a look at a specific example: the kde keyword. If you do not 
have this keyword in your USE variable, all packages that have optional 
KDE support will be compiled without KDE support. All packages that have 
an optional KDE dependency will be installed without installing the KDE 
libraries (as dependency). If you have defined the kde keyword, then 
those packages will be compiled with KDE support, and the KDE libraries 
will be installed as dependency.

_By correctly defining the keywords you will receive a system tailored 
specifically to your needs._ "

It's just my 2 cents...

Abelenda David

Thomas Bluemel a écrit :
>   Instead of actually removing this stuff from trunk,
> can't we drive this 
>  by an environment variable with rbuild so that it skips building modules 
>  not neccessary?
>
>  Thomas
>  Aleksey Bragin wrote:
>    
> >   So, are there any objections in separating
> > thirdparty, additional, 
> >  sometimes helpful stuff into addons module, and having all apps which 
> >  exist in Windows, but aren't required for booting into rosapps?
> >
> >  Please, let's come to a solution, because having such a trash can which 
> >  rosapps is now is unbearable.
> >
> >
> >  WBR,
> >  Aleksey Bragin.
> >
> >  On Mar 9, 2009, at 2:50 AM, Ged wrote:
> >
> >      
> > >   I would opt for deleting everything in rosapps.
> > >
> > >  I’m not really sure why it’s important to start rearranging it as 
> > >  there’s very little of use in there.
> > >
> > >   
> > >
> > >  As per our project mandate we aren’t interested in anything which 
> > >  isn’t core.
> > >
> > >   
> > >
> > >  Ged.
> > >
> > >   
> > >
> > >   
> > >
> > >  *From:* ros-dev-bounces(a)reactos.org 
> > >  [mailto:[e-mail]] *On Behalf Of *Aleksey Bragin
> > >  *Sent:* 08 March 2009 18:16
> > >  *To:* ReactOS Development List
> > >  *Subject:* Re: [ros-dev] rosapps
> > >
> > >   
> > >
> > >  I'll explain his idea.
> > >
> > >   
> > >
> > >  The idea he would likes to propose is to separate the mess inside 
> > >  rosapps, and provide a clear division of what goes where:
> > >
> > >  1. trunk/reactos contains ONLY stuff which is vital for the system to 
> > >  work minimally. Including explorer, GUI, and things like that, but 
> > >  without calculator, solitaire, or anything like that.
> > >
> > >  2. rosapps - components similar to those present in Windows, but not 
> > >  vital for the boot process.
> > >
> > >  3. addons - components, which are additional to the base set of apps 
> > >  and drivers Windows ships with.
> > >
> > >   
> > >
> > >  Comments are welcome on his idea.
> > >
> > >   
> > >
> > >  My own comment is that the idea seems to recall what we originally 
> > >  been discussing a year or more ago, but stopped caring as more devs 
> > >  got more powerful PCs. There is no strict solution on what goes where 
> > >  now, actually that's why his idea started - he proposed to move winver 
> > >  and winhlp back to trunk, and I was arguing over it.
> > >
> > >   
> > >
> > >   
> > >
> > >  WBR,
> > >
> > >  Aleksey Bragin.
> > >
> > >   
> > >
> > >   
> > >
> > >  On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
> > >
> > >
> > >
> > >  Huh?  The rosapps module isn't included by default in the build to 
> > >  begin with, so how does it decrease build time?  Also, the 
> > >  applications in there are supposed to be providing equivalent 
> > >  functionality found in Windows.  Downloader is an exception, but what 
> > >  else is?
> > >
> > >  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru 
> > >  <mailto:[e-mail]>> wrote:
> > >
> > >  Hi.
> > >
> > >  I suggest to divide rosapps on two parts:
> > >
> > >  1) Components which are present in Windows (rosapps)
> > >  2) 3rd party components (3rdapps)
> > >
> > >  In rosapps it is necessary to place all components without which the
> > >  system can normally work (calc, hh, winhlp32, charmap, games and etc)
> > >
> > >  In 3rdapps components which are not present in Windows (downloader,
> > >  imagesoft and etc) will take places
> > >
> > >  Such placing of components will allow to reduce compilation time as you
> > >  can not compile not the modules necessary to you (rosapps and/or 3rdapps)
> > >
> > >  Please tell your opinion on my proposition.
> > >
> > >         
> >  ------------------------------------------------------------------------
> >
> >  _______________________________________________
> >  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
>
>

[Timo Kreuzer]

I would even like to go one step further in the long run.

The current situation is that rosbuild takes about 10 minutes for a
build. With adding more code and more modules to our codebase, this time
will increase. If we wanted to do something like auto-rejecting commits
that break build it would lock the commit process for this time on every
commit.

Also as we get more developers and maybe start forming teams or
whatever, things will get problematic with our current "monolithic"
approach.

We should think of changing the build process, so that not the whole
system is rebuild everytime someone changes one module.
We currently treat reactos like one huge module, but it isn't. It's a
bunch of more or less independent things. A change in a usermode dll
should not lead to an notskrnl recompile, it just doesn't make sense and
only wastes time.

I think it would be better to seperate the components from each other as
much as possible and only compile the modules that have been changed.

Of cause all modules somehow depend on each other, but mostly through
well defined interfaces. These are exposed by the headers and import
libraries. And those 2 are the problem atm.
It might be a good idea to completely separate the sdk from the os
itself. The sdk would contain both the headers and the spec files to
build the import libraries. If we made sure these are in a good shape,
we would eleminate most interdependencies as they should only rarely change.

We could try to split the current reactos tree into seperate trees,
maybe like this:
sdk: headers, import library definitions, crt
core: rtl, freeldr, hal, ntoskrnl, boot drivers, ntdll, smss
drivers: other hardware drivers
win32core: win32k, video drivers, gdi32, user32, csrss
win32dll: the other win32 dlls
sound: everything related to sound
network: everything related to network
reactx
services
apps

Some of these trees could be optional, like network, sound, reactx
It might even allow to create a bootable core system without win32
stuff, booting into a simple native console.
Working with branches might as well profit from this.

Just my 2 cents,
Timo


Aleksey Bragin wrote:
>   I'll explain his idea.
>
>  The idea he would likes to propose is to separate the mess inside
>  rosapps, and provide a clear division of what goes where:
>  1. trunk/reactos contains ONLY stuff which is vital for the system to
>  work minimally. Including explorer, GUI, and things like that, but
>  without calculator, solitaire, or anything like that.
>  2. rosapps - components similar to those present in Windows, but not
>  vital for the boot process.
>  3. addons - components, which are additional to the base set of apps
>  and drivers Windows ships with.
>
>  Comments are welcome on his idea.
>
>  My own comment is that the idea seems to recall what we originally
>  been discussing a year or more ago, but stopped caring as more devs
>  got more powerful PCs. There is no strict solution on what goes where
>  now, actually that's why his idea started - he proposed to move winver
>  and winhlp back to trunk, and I was arguing over it.
>
>
>  WBR,
>  Aleksey Bragin.
>
>
>  On Mar 8, 2009, at 7:02 PM, Zachary Gorden wrote:
>
> >   Huh?  The rosapps module isn't included by
> > default in the build to
> >  begin with, so how does it decrease build time?  Also, the
> >  applications in there are supposed to be providing equivalent
> >  functionality found in Windows.  Downloader is an exception, but what
> >  else is?
> >
> >  On Sun, Mar 8, 2009 at 8:00 AM, Dmitry Chapyshev <lentind(a)yandex.ru>
> >  wrote:
> >  Hi.
> >
> >  I suggest to divide rosapps on two parts:
> >
> >  1) Components which are present in Windows (rosapps)
> >  2) 3rd party components (3rdapps)
> >
> >  In rosapps it is necessary to place all components without which the
> >  system can normally work (calc, hh, winhlp32, charmap, games and etc)
> >
> >  In 3rdapps components which are not present in Windows (downloader,
> >  imagesoft and etc) will take places
> >
> >  Such placing of components will allow to reduce compilation time as you
> >  can not compile not the modules necessary to you (rosapps and/or
> >  3rdapps)
> >
> >  Please tell your opinion on my proposition.
> >
> >  -- 
> >  WBR,
> >  Dmitry Chapyshev
> >  _______________________________________________
> >  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 
>
>  ------------------------------------------------------------------------
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[James Tabor]

Hi!

2009/3/8 Timo Kreuzer <timo.kreuzer(a)web.de>de>:
>   I would even like to go one step further in the long
> run.
>
>  The current situation is that rosbuild takes about 10 minutes for a build.
>  With adding more code and more modules to our codebase, this time will
>  increase. If we wanted to do something like auto-rejecting commits that
>  break build it would lock the commit process for this time on every commit.
>
>  Also as we get more developers and maybe start forming teams or whatever,
>  things will get problematic with our current "monolithic" approach.
>
>  We should think of changing the build process, so that not the whole system
>  is rebuild everytime someone changes one module.
>  We currently treat reactos like one huge module, but it isn't. It's a bunch
>  of more or less independent things. A change in a usermode dll should not
>  lead to an notskrnl recompile, it just doesn't make sense and only wastes
>  time.
>
>  I think it would be better to seperate the components from each other as
>  much as possible and only compile the modules that have been changed.
>
>  Of cause all modules somehow depend on each other, but mostly through well
>  defined interfaces. These are exposed by the headers and import libraries.
>  And those 2 are the problem atm.
>  It might be a good idea to completely separate the sdk from the os itself.
>  The sdk would contain both the headers and the spec files to build the
>  import libraries. If we made sure these are in a good shape, we would
>  eleminate most interdependencies as they should only rarely change.
>
>  We could try to split the current reactos tree into seperate trees, maybe
>  like this:
>  sdk: headers, import library definitions, crt
>  core: rtl, freeldr, hal, ntoskrnl, boot drivers, ntdll, smss
>  drivers: other hardware drivers
>  win32core: win32k, video drivers, gdi32, user32, csrss 
Core DLLs: ntdll, kernel32, gdi32, user32 and sometimes advapi32.

>   win32dll: the other win32 dlls
>  sound: everything related to sound
>  network: everything related to network
>  reactx
>  services
>  apps
>
>  Some of these trees could be optional, like network, sound, reactx
>  It might even allow to create a bootable core system without win32 stuff,
>  booting into a simple native console.
>  Working with branches might as well profit from this.
>
>  Just my 2 cents,
>  Timo
>
>

[KJK::Hyperion]

Timo Kreuzer wrote:
>   I think it would be better to seperate the components
> from each other as
>  much as possible and only compile the modules that have been changed. 
It doesn't work. And you know why? because it's already implemented. And
it doesn't work. People fuck with the SDK all the time. They piggyback
SDK changes on two-liner commits, amplifying the two lines millionfold
into a cascade of useless recompilations and relinkings. They sync Wine
modules every time Alexandre Julliard so much as farts in their general
direction, making sure to pick all the goddamn modules with public IDLs,
which results in an SDK rebuild, which results in rebuilding 99% of the
tree because an attribute that was previously unimplemented in rpcrt4
was uncommented in a bumfuck IDL somewhere. When you call out people on
this shit, "but syncing every point-point Wine release is _important_"
is the usual defense, and you can't argue with meatheaded truisms (in
fact, my plan is to slowly commit the rug from under them, but that
takes time)

Nobody gives a flying fuck about this. Try "full dependencies" some time
(add -df to the rbuild command line), only do incremental builds for a
week or two, and become frustrated at SDK retardation in an _informed_
way when you get a string of a half dozen near-full rebuilds after you
have gotten used to 5-minute incremental builds, and absolutely nobody
sees an issue with it because the build server has a trillion cores and
a quintillion terabytes of RAM

>   We could try to split the current reactos tree into
> seperate trees,
>  maybe like this: 
Oh how I _love_ itemized lists. Seems the solution to humanity's every
problem has to start with a goddamn itemized list

[Timo Kreuzer]

Hahaha, love it ;-)

I understand it like this:
"It's shit atm, even with everything I tried it stays shit. So whatever
you do it will always stay shit. It's natural born shit. Shit for life.
Goddam shit even."
or like
"Changing it won't work, because it doesn't work already and we already
do it like that so we don't actually change anything. So you better not
change it as changing it won't change anything."

You only ignored that you don't even have to sync every fckng sdk
change. Do you update rosapps after every commit? Everytime you update
reatcos? Probably not. Probably only when something doesn't compile anymore.
Choose for yourself to update your sdk and rebuild everything or don't
do it.
The fucking idea behind seperating it. Independency.

It might also keep people from randomly updating the sdk as long as it's
not needed, or it could well be done in a branch that can be synched
once a month or as soon as any change is really neccessary for other
development.

The suggested solution is about making independency more natural, more
apparent, more concrete, more controllable than the current "I trust in
rbuild" solution, that obviously leads to nowhere.

btw, rbuild and the other build tools could be seperated, too. So you
also have the choice to sync the goddam rbuild changes or not.

I don't know if a "goddam itemized list" will solve any problem, but it
feels good to have talked about it....
It's about splitting things that get too large, outsourcing,
abstraction. It's natural, evolutional.

Timo


KJK::Hyperion schrieb:
>   Timo Kreuzer wrote:
>    
> >   I think it would be better to seperate the
> > components from each other as
> >  much as possible and only compile the modules that have been changed.
> >       
>  It doesn't work. And you know why? because it's already implemented. And
>  it doesn't work. People fuck with the SDK all the time. They piggyback
>  SDK changes on two-liner commits, amplifying the two lines millionfold
>  into a cascade of useless recompilations and relinkings. They sync Wine
>  modules every time Alexandre Julliard so much as farts in their general
>  direction, making sure to pick all the goddamn modules with public IDLs,
>  which results in an SDK rebuild, which results in rebuilding 99% of the
>  tree because an attribute that was previously unimplemented in rpcrt4
>  was uncommented in a bumfuck IDL somewhere. When you call out people on
>  this shit, "but syncing every point-point Wine release is _important_"
>  is the usual defense, and you can't argue with meatheaded truisms (in
>  fact, my plan is to slowly commit the rug from under them, but that
>  takes time)
>
>  Nobody gives a flying fuck about this. Try "full dependencies" some time
>  (add -df to the rbuild command line), only do incremental builds for a
>  week or two, and become frustrated at SDK retardation in an _informed_
>  way when you get a string of a half dozen near-full rebuilds after you
>  have gotten used to 5-minute incremental builds, and absolutely nobody
>  sees an issue with it because the build server has a trillion cores and
>  a quintillion terabytes of RAM
>
>    
> >   We could try to split the current reactos tree
> > into seperate trees,
> >  maybe like this:
> >       
>  Oh how I _love_ itemized lists. Seems the solution to humanity's every
>  problem has to start with a goddamn itemized list
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Aleksey Bragin]

It might be implemented as a subset of "make XXX", where XXX would be  
that core, drivers or anything like that - but all from one tree,  
just a different sets. Otherwise than that, splitting them physically  
into different modules is going to only hurt the development, not  
make it easier. I already thought about that, but I'm afraid it won't  
work.


Oh, actually, Marc Piulachs already implemented all of that in his  
platform builder, so he's able to pick necessary modules with a click  
of a mouse, and produce an installation CD consisting of such  
"modules", and it indeed works. It just is not separated physically  
in the tree itself.


WBR,
Aleksey Bragin.

On Mar 9, 2009, at 4:20 AM, Timo Kreuzer wrote:

>   I would even like to go one step further in the long
> run.
>
>  The current situation is that rosbuild takes about 10 minutes for a  
>  build. With adding more code and more modules to our codebase, this  
>  time will increase. If we wanted to do something like auto- 
>  rejecting commits that break build it would lock the commit process  
>  for this time on every commit.
>
>  Also as we get more developers and maybe start forming teams or  
>  whatever, things will get problematic with our current "monolithic"  
>  approach.
>
>  We should think of changing the build process, so that not the  
>  whole system is rebuild everytime someone changes one module.
>  We currently treat reactos like one huge module, but it isn't. It's  
>  a bunch of more or less independent things. A change in a usermode  
>  dll should not lead to an notskrnl recompile, it just doesn't make  
>  sense and only wastes time.
>
>  I think it would be better to seperate the components from each  
>  other as much as possible and only compile the modules that have  
>  been changed.
>
>  Of cause all modules somehow depend on each other, but mostly  
>  through well defined interfaces. These are exposed by the headers  
>  and import libraries. And those 2 are the problem atm.
>  It might be a good idea to completely separate the sdk from the os  
>  itself. The sdk would contain both the headers and the spec files  
>  to build the import libraries. If we made sure these are in a good  
>  shape, we would eleminate most interdependencies as they should  
>  only rarely change.
>
>  We could try to split the current reactos tree into seperate trees,  
>  maybe like this:
>  sdk: headers, import library definitions, crt
>  core: rtl, freeldr, hal, ntoskrnl, boot drivers, ntdll, smss
>  drivers: other hardware drivers
>  win32core: win32k, video drivers, gdi32, user32, csrss
>  win32dll: the other win32 dlls
>  sound: everything related to sound
>  network: everything related to network
>  reactx
>  services
>  apps
>
>  Some of these trees could be optional, like network, sound, reactx
>  It might even allow to create a bootable core system without win32  
>  stuff, booting into a simple native console.
>  Working with branches might as well profit from this.
>
>  Just my 2 cents,
>  Timo
>

[Alex Ionescu]

I'm attaching some rbuild files I used before:



On 9-Mar-09, at 4:40 AM, Aleksey Bragin wrote:

>   It might be implemented as a subset of "make
> XXX", where XXX would be
>  that core, drivers or anything like that - but all from one tree,
>  just a different sets. Otherwise than that, splitting them physically
>  into different modules is going to only hurt the development, not
>  make it easier. I already thought about that, but I'm afraid it won't
>  work.
>
>
>  Oh, actually, Marc Piulachs already implemented all of that in his
>  platform builder, so he's able to pick necessary modules with a click
>  of a mouse, and produce an installation CD consisting of such
>  "modules", and it indeed works. It just is not separated physically
>  in the tree itself.
>
>
>  WBR,
>  Aleksey Bragin.
>
>  On Mar 9, 2009, at 4:20 AM, Timo Kreuzer wrote:
>
> >   I would even like to go one step further in the
> > long run.
> >
> >  The current situation is that rosbuild takes about 10 minutes for a
> >  build. With adding more code and more modules to our codebase, this
> >  time will increase. If we wanted to do something like auto-
> >  rejecting commits that break build it would lock the commit process
> >  for this time on every commit.
> >
> >  Also as we get more developers and maybe start forming teams or
> >  whatever, things will get problematic with our current "monolithic"
> >  approach.
> >
> >  We should think of changing the build process, so that not the
> >  whole system is rebuild everytime someone changes one module.
> >  We currently treat reactos like one huge module, but it isn't. It's
> >  a bunch of more or less independent things. A change in a usermode
> >  dll should not lead to an notskrnl recompile, it just doesn't make
> >  sense and only wastes time.
> >
> >  I think it would be better to seperate the components from each
> >  other as much as possible and only compile the modules that have
> >  been changed.
> >
> >  Of cause all modules somehow depend on each other, but mostly
> >  through well defined interfaces. These are exposed by the headers
> >  and import libraries. And those 2 are the problem atm.
> >  It might be a good idea to completely separate the sdk from the os
> >  itself. The sdk would contain both the headers and the spec files
> >  to build the import libraries. If we made sure these are in a good
> >  shape, we would eleminate most interdependencies as they should
> >  only rarely change.
> >
> >  We could try to split the current reactos tree into seperate trees,
> >  maybe like this:
> >  sdk: headers, import library definitions, crt
> >  core: rtl, freeldr, hal, ntoskrnl, boot drivers, ntdll, smss
> >  drivers: other hardware drivers
> >  win32core: win32k, video drivers, gdi32, user32, csrss
> >  win32dll: the other win32 dlls
> >  sound: everything related to sound
> >  network: everything related to network
> >  reactx
> >  services
> >  apps
> >
> >  Some of these trees could be optional, like network, sound, reactx
> >  It might even allow to create a bootable core system without win32
> >  stuff, booting into a simple native console.
> >  Working with branches might as well profit from this.
> >
> >  Just my 2 cents,
> >  Timo
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 
Best regards,
Alex Ionescu

[Timo Kreuzer]

Yes that might already hit it, when it's properly implemented.
Though I think a physical seperation might add some additional
advantages, especially when
it comes to managing an increasing mass of resources.

One thing that has bugged me when working with the x64 branch was that
everything depends on so much other stuff.
It's not possible to disable the apps folder, as the dll folder depends
on it and vice versa. Some hacking was required
So I added the usermode rbuild switch. still you can't just
remove/diable something. And when you want to clean parts of your
local copy, you will have to rebuild or at least relink all stuff that
depends on it.

make ntdll clean
make
will relink all usermode dlls :(

So moving the import libraries to an sdk module group would unlink the
modules and make it easier to
build/clean parts of them without effecting the others.

And for some reason, changing one rbuild file will at random times lead
to a recompile of rbuild which will then lead to a recompile of
everything else. and that sucks a lot.

ok it finally ends up with ranting about rbuild....


Aleksey Bragin schrieb:
>   It might be implemented as a subset of "make
> XXX", where XXX would be  
>  that core, drivers or anything like that - but all from one tree,  
>  just a different sets. Otherwise than that, splitting them physically  
>  into different modules is going to only hurt the development, not  
>  make it easier. I already thought about that, but I'm afraid it won't  
>  work.
>
>
>  Oh, actually, Marc Piulachs already implemented all of that in his  
>  platform builder, so he's able to pick necessary modules with a click  
>  of a mouse, and produce an installation CD consisting of such  
>  "modules", and it indeed works. It just is not separated physically  
>  in the tree itself.
>
>
>  WBR,
>  Aleksey Bragin.
>
>  On Mar 9, 2009, at 4:20 AM, Timo Kreuzer wrote:
>
>    
> >   I would even like to go one step further in the
> > long run.
> >
> >  The current situation is that rosbuild takes about 10 minutes for a  
> >  build. With adding more code and more modules to our codebase, this  
> >  time will increase. If we wanted to do something like auto- 
> >  rejecting commits that break build it would lock the commit process  
> >  for this time on every commit.
> >
> >  Also as we get more developers and maybe start forming teams or  
> >  whatever, things will get problematic with our current "monolithic"  
> >  approach.
> >
> >  We should think of changing the build process, so that not the  
> >  whole system is rebuild everytime someone changes one module.
> >  We currently treat reactos like one huge module, but it isn't. It's  
> >  a bunch of more or less independent things. A change in a usermode  
> >  dll should not lead to an notskrnl recompile, it just doesn't make  
> >  sense and only wastes time.
> >
> >  I think it would be better to seperate the components from each  
> >  other as much as possible and only compile the modules that have  
> >  been changed.
> >
> >  Of cause all modules somehow depend on each other, but mostly  
> >  through well defined interfaces. These are exposed by the headers  
> >  and import libraries. And those 2 are the problem atm.
> >  It might be a good idea to completely separate the sdk from the os  
> >  itself. The sdk would contain both the headers and the spec files  
> >  to build the import libraries. If we made sure these are in a good  
> >  shape, we would eleminate most interdependencies as they should  
> >  only rarely change.
> >
> >  We could try to split the current reactos tree into seperate trees,  
> >  maybe like this:
> >  sdk: headers, import library definitions, crt
> >  core: rtl, freeldr, hal, ntoskrnl, boot drivers, ntdll, smss
> >  drivers: other hardware drivers
> >  win32core: win32k, video drivers, gdi32, user32, csrss
> >  win32dll: the other win32 dlls
> >  sound: everything related to sound
> >  network: everything related to network
> >  reactx
> >  services
> >  apps
> >
> >  Some of these trees could be optional, like network, sound, reactx
> >  It might even allow to create a bootable core system without win32  
> >  stuff, booting into a simple native console.
> >  Working with branches might as well profit from this.
> >
> >  Just my 2 cents,
> >  Timo
> >
> >       
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>