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

[Kent Fredric]

On 3 May 2015 at 10:18, Georg Rudoy <0xd34df00d@×××××.com> wrote:

> We have "idn" or "gnutls" or "python" etc USE flags after all, not
> "support_international_names_in_blah" or
> "allow_secure_news_fetching_in_foo" or "build_scripting_support_for_baz".
>
> Or I just didn't get you here, sorry me in this case :)
>


The difference is semantics.

"idn" *is* saying "Support for international names" ( not in, but _for_ )

and python very often *is* saying "Support for python" ( not in, but _for_ )

That's "for", not "by".  For support *by* python, an explicit python
use-flag is not entirely necessary.

Just like you presently don't have ( and we don't have ) a "USE=c" flag
just to make sure you have a C compiler.

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 for instance a specific user visible tool became magically available
with "USE=C++14", and that was the only tool that became visible as a
result, that would, for example, be really silly.

If a useflag doesn't tell me what it does for me, then what impetus is
there for me to toggle it?

For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have
one.

It does however have a USE=crypt flag, which utilizes perl as part of its
work. ( And its only a compile time dependency also ).

But you seem to want USE=perl # turn on crypt features

Which is inherently backwards.

There is still places where that makes a degree of sense, but in cases like
"give new user facing features features" an ambiguous "C++" toggle is not
going to be communicating intent in an appropriate manner.

-- 
Kent

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