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.
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@yandex.ru wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@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?
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@yandex.ru wrote: Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org [mailto:ros-dev-bounces@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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
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@reactos.org [mailto:ros-dev- bounces@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:
- 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.
- rosapps - components similar to those present in Windows, but
not vital for the boot process.
- 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@yandex.ru wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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.
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@reactos.org [mailto:ros-dev-bounces@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:
- 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.
- rosapps - components similar to those present in Windows, but not
vital for the boot process.
- 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@yandex.ru mailto:lentind@yandex.ru> wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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.
- 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.
2009/3/12 Aleksey Bragin aleksey@reactos.org:
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.
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.
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@reactos.org:
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
- Changes to base,user, services, whatever that does not affect
another module can go in the tree 24x7
- 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
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
On Thu, Mar 12, 2009 at 10:16 AM, Aleksey Bragin aleksey@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.
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@reactos.org [mailto:ros-dev-bounces@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:
- 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.
- rosapps - components similar to those present in Windows, but not
vital for the boot process.
- 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@yandex.ru mailto:lentind@yandex.ru> wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org [mailto:ros-dev-bounces@reactos.org] 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@reactos.org [mailto:ros-dev-bounces@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:
- 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.
- rosapps - components similar to those present in Windows, but not
vital for the boot process.
- 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@yandex.ru mailto:lentind@yandex.ru> wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@reactos.org [mailto:ros-dev-bounces@reactos.org] 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@reactos.org [mailto:ros-dev-bounces@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:
- 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.
- rosapps - components similar to those present in Windows, but not
vital for the boot process.
- 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@yandex.ru mailto:lentind@yandex.ru> wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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.
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.
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
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
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
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.
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" aleksey@reactos.org Sent: Friday, March 27, 2009 1:49 PM To: "ReactOS Development List" ros-dev@reactos.org 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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_cha...:
"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@reactos.org [mailto:ros-dev-bounces@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:
- 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.
- rosapps - components similar to those present in Windows, but not
vital for the boot process.
- 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@yandex.ru mailto:lentind@yandex.ru> wrote:
Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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:
- 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@yandex.ru wrote: Hi.
I suggest to divide rosapps on two parts:
- Components which are present in Windows (rosapps)
- 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi!
2009/3/8 Timo Kreuzer timo.kreuzer@web.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
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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Aleksey Bragin -
Alex Ionescu -
blastos＠infomaniak.ch -
Colin Finck -
Dmitry Chapyshev -
Dmitry Gorbachev -
Ged -
James Tabor -
KJK::Hyperion -
Komarov Alexey -
Marc Piulachs -
Steven Edwards -
Thomas Bluemel -
Timo Kreuzer -
Zachary Gorden