On 3 May 2015 at 10:18, Georg Rudoy <0xd34df...@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. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
