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