12 Mar
2009
12 Mar
'09
9:01 p.m.
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:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)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(a)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(a)yandex.ru
<mailto: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.
------------------------------------------------------------------------
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev