Re: [gentoo-dev] Re: RFC: c++14 global USE flag

[Kent Fredric]

On 4 May 2015 at 02:04, Georg Rudoy <0xd34df00d@×××××.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