On K, 2010-06-23 at 09:33 +0530, Arun Raghavan wrote:
> On 23 June 2010 01:47, Mike Auty <email@example.com> wrote:
> >> Which should not be an issue since any library that has some sort of
> >> introspection can use this flag (and the use.desc can be changed
> >> appropriately at that time if it does not use gobject-introspection).
> > Why have to change it in the future (and probably split it into two
> > flags then), when the choice hasn't been made yet? Or, to put your own
> > question to you, why are you vehemently for "introspection" when others
> > have shown concern with the choice? As far as I can see, the only
> > difference is requiring a slightly longer use_enable line.
> Mostly because I don't want to coin a new term if it's not absolutely necessary.
> That said, you're right - more people seem to be comfortable with
> "gintrospection" than plain "introspection". If no further objections
> arise, we'll go with "gintrospection".
gintrospection doesn't describe anything. It's very hard to understand
from the USE flag name that it deals with introspection, as opposed, to,
uh, gint's or who knows what.
USE flags starting with "g" usually denote support for some GNU package,
not gnome, per some actual looking at use.desc.
Nothing stops QtCore packages to use the same USE flag name for the same
purpose - introspection. USE flags are primarily supposed to enable
certain functionality, not "allow to depend on this package". That
functionality is introspection. It just happens that the only framework
this is currently supported in is on top of GObject and the appropriate
Introspection has nothing to do with GNOME. Most GNOME modules are
written in C and don't need introspection information (primary exception
depend on PyGTK will and should eventually use PyGi and in turn the
introspection information provided by the necessary used libraries. This
includes many GUI software that has no relation to GNOME, other than
using the same toolkit.
I can't imagine what else introspection means than what this USE flag is
proposed to provide to many libraries (would api-introspection be more
clear?), all of which just happen to be GObject based right now (and as
such detailed in the currently proposed global USE flag description), as
other base frameworks currently don't have any introspection support to
Note that you will soon not be able to really avoid
gobject-introspection package on desktop systems (unless you are a Qt
junky that refuses to install anything not based on Qt), so this USE
flag really isn't about dependency control at all. It's about defining
if embedded images need a .typelib introspection file at runtime or not.
So that embedded GUI image builders would be able to globally disable
the USE flag and enable it per-package as necessary by applications
(represented with USE depends). If it weren't for that, we'd simply
always install them, they are just not that big compared to the include
files that get always installed too. But embedded guys can easily delete
all of /usr/include, but typelibs (containing the introspection data)
may be necessary at runtime.