[ros-dev] rosapps

Ged gedmurphy at gmail.com
Thu Mar 12 15:59:08 CET 2009


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 at reactos.org [mailto:ros-dev-bounces at 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 at reactos.org 
>> [mailto:ros-dev-bounces at 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 at yandex.ru 
>> <mailto:lentind at 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.
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev

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



More information about the Ros-dev mailing list