public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Re: RFC: c++14 global USE flag
Date: Mon, 4 May 2015 07:07:21 +1200	[thread overview]
Message-ID: <CAATnKFD0dLUkjciKb--r=ytxeLkkSBh0vecjS5EVSnHW=EKmtA@mail.gmail.com> (raw)
In-Reply-To: <CAGbUWSJfF9j1wGVH5ezunJspaUFa3ZrnF8o4ssgFcrXUokLFOw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

On 4 May 2015 at 02:04, Georg Rudoy <0xd34df00d@gmail.com> wrote:

> Why should the user care if python is supported? What does python support
> per se offer to the user? I would argue that what's important are the
> features exposed via Python stuff (unless the user theyself is expected to
> write some Python code, of course).
>
>
By support "for" python, I mean "This flag exposes a new feature to
userspace".

For instance, it may install python modules that a user may desire to
consume in the course of their programming.

Thus, they are not likely to want that flag on, unless they are doing
exactly that.

Or a dependant may require those modules to be available, and may depend on
that package with the flag enabled to access those libraries.

Thus, the "feature" that the flag exposes is "Support for people or code
who explicitly need something python related in using it".

Same logic applies for C++14, IMHO.
>

The same logic here would be:

- People are developing their own code for leechcraft that needs leechcraft
to be compiled differently for them to do that, and that flag changes how
leechcraft is compiled so that they can do that
- Some dependent is in the above situation, and wishes to be able to force
leechcraft to be compiled so that it may work.

Simply put: "Compiled using C++14" is not a "feature" unless somebody
somewhere explicitly needs C++14 compilation.


>
>> What does it matter to a user that its in C++14 ? It doesn't.
>>
> And end user is more concerned with "what does this do for me".
>>
>> If a useflag doesn't tell me what it does for me, then what impetus is
>> there for me to toggle it?
>>
>
> The consequences do matter, like pulling and building llvm/clang, if not
> present already. Toggle it if you're ready to deal with the consequences
> (having clang in your system, particularly).
>
> Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user
> care if it's llvm or whatever?
>
>
>
For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have
>> one.
>>
>
> Nice example with USE=perl, thanks! git has that, for instance. Without
> that, `git add -i` won't work, but I still have USE=perl, not
> USE=add_interactive and possibly a bunch of other features depending on
> Perl that would pull it when enabled.
>

Right, its not a black/white thing, and I would argue that flag on git is
poorly named.

But the general pattern is its recommended to express useflags to users in
terms of "things I can see will be useful to me", thus, if you can make a
more purpose-specific flag, it is wise to do so.

Its not that doing it that way is "wrong" per say. Just a sub-optimal
choice that requires more thinking.

-- 
Kent

*KENTNL* - https://metacpan.org/author/KENTNL

[-- Attachment #2: Type: text/html, Size: 5225 bytes --]

  reply	other threads:[~2015-05-03 19:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 18:12 [gentoo-dev] RFC: c++14 global USE flag Maxim Koltsov
2015-04-24 18:42 ` Ciaran McCreesh
2015-04-24 18:56   ` Ian Stakenvicius
2015-04-24 19:11     ` Maxim Koltsov
2015-04-24 19:28       ` Georg Rudoy
2015-04-25 14:09     ` Anthony G. Basile
2015-04-25 15:23       ` Peter Stuge
2015-04-25 15:57         ` [gentoo-dev] " Duncan
2015-04-26 16:41           ` Diego Elio Pettenò
2015-04-27  3:21             ` Duncan
2015-04-28 20:07               ` Anthony G. Basile
2015-04-28 21:52                 ` Mike Gilbert
2015-04-29 11:27                   ` Anthony G. Basile
2015-05-02 21:11                     ` Maxim Koltsov
2015-05-02 21:17                       ` Kent Fredric
2015-05-02 22:18                         ` Georg Rudoy
2015-05-02 22:30                           ` Kent Fredric
2015-05-03 10:19                             ` Maxim Koltsov
2015-05-03 10:51                               ` Duncan
2015-05-03 14:13                                 ` Georg Rudoy
2015-05-04  4:36                                   ` Duncan
2015-05-03 14:08                               ` Georg Rudoy
2015-05-03 14:04                             ` Georg Rudoy
2015-05-03 19:07                               ` Kent Fredric [this message]
2015-05-04  3:29                               ` Duncan
2015-04-25 15:47       ` [gentoo-dev] " Matthias Maier

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='CAATnKFD0dLUkjciKb--r=ytxeLkkSBh0vecjS5EVSnHW=EKmtA@mail.gmail.com' \
    --to=kentfredric@gmail.com \
    --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