From: Mart Raudsepp <leio@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: New global USE flag: introspection
Date: Fri, 25 Jun 2010 17:56:16 +0300 [thread overview]
Message-ID: <1277477776.4920.24.camel@localhost> (raw)
In-Reply-To: <AANLkTik8TchYYuPP946ByKa86aPk_fWkFOSryK_aF_MN@mail.gmail.com>
On K, 2010-06-23 at 09:33 +0530, Arun Raghavan wrote:
> On 23 June 2010 01:47, Mike Auty <ikelos@gentoo.org> 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".
I object.
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
gobject-introspection package.
Introspection has nothing to do with GNOME. Most GNOME modules are
written in C and don't need introspection information (primary exception
being gnome-shell and its javascript stuff). All packages that currently
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
our knowledge.
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.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://blogs.gentoo.org/leio
next prev parent reply other threads:[~2010-06-25 15:03 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-20 14:42 [gentoo-dev] New global USE flag: introspection Arun Raghavan
2010-06-20 19:37 ` [gentoo-dev] " Pacho Ramos
2010-06-20 21:35 ` Nirbheek Chauhan
2010-06-20 21:53 ` Pacho Ramos
2010-06-20 20:14 ` [gentoo-dev] " Olivier Crête
2010-06-20 21:33 ` Nirbheek Chauhan
2010-06-20 22:55 ` Brian Harring
2010-06-20 23:33 ` Nirbheek Chauhan
2010-06-21 4:43 ` Arun Raghavan
2010-06-21 7:10 ` Michał Górny
2010-06-21 4:44 ` [gentoo-dev] " Arun Raghavan
2010-06-21 6:13 ` Alexis Ballier
2010-06-21 6:53 ` Arun Raghavan
2010-06-21 7:03 ` Alexis Ballier
2010-06-21 7:04 ` "Paweł Hajdan, Jr."
2010-06-21 9:07 ` Duncan
2010-06-21 13:46 ` Olivier Crête
2010-06-21 14:49 ` Duncan
2010-06-21 13:55 ` René 'Necoro' Neumann
2010-06-21 7:33 ` [gentoo-dev] " Maciej Mrozowski
2010-06-21 14:22 ` Olivier Crête
2010-06-21 15:44 ` Maciej Mrozowski
2010-06-21 15:53 ` Arun Raghavan
2010-06-22 9:47 ` Arun Raghavan
2010-06-22 11:24 ` [gentoo-dev] " Peter Hjalmarsson
2010-06-22 14:33 ` Arun Raghavan
2010-06-22 16:33 ` Mike Auty
2010-06-22 17:11 ` Arun Raghavan
2010-06-22 20:17 ` Mike Auty
2010-06-23 4:03 ` Arun Raghavan
2010-06-25 14:56 ` Mart Raudsepp [this message]
2010-06-22 18:00 ` Jacob Godserv
2010-06-21 14:49 ` [gentoo-dev] " Nirbheek Chauhan
2010-06-22 17:14 ` [gentoo-dev] " Arun Raghavan
2010-07-23 13:14 ` Maciej Mrozowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1277477776.4920.24.camel@localhost \
--to=leio@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox