On 3 May 2015 at 10:18, Georg Rudoy <0xd34df00d@gmail.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.