| 1 |
2015-05-03 1:30 GMT+03:00 Kent Fredric <kentfredric@×××××.com>: |
| 2 |
|
| 3 |
> and python very often *is* saying "Support for python" ( not in, but _for_ |
| 4 |
> ) |
| 5 |
> |
| 6 |
|
| 7 |
Why should the user care if python is supported? What does python support |
| 8 |
per se offer to the user? I would argue that what's important are the |
| 9 |
features exposed via Python stuff (unless the user theyself is expected to |
| 10 |
write some Python code, of course). |
| 11 |
|
| 12 |
Same logic applies for C++14, IMHO. |
| 13 |
|
| 14 |
|
| 15 |
> What does it matter to a user that its in C++14 ? It doesn't. |
| 16 |
> |
| 17 |
And end user is more concerned with "what does this do for me". |
| 18 |
> |
| 19 |
> If a useflag doesn't tell me what it does for me, then what impetus is |
| 20 |
> there for me to toggle it? |
| 21 |
> |
| 22 |
|
| 23 |
The consequences do matter, like pulling and building llvm/clang, if not |
| 24 |
present already. Toggle it if you're ready to deal with the consequences |
| 25 |
(having clang in your system, particularly). |
| 26 |
|
| 27 |
Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user care |
| 28 |
if it's llvm or whatever? |
| 29 |
|
| 30 |
|
| 31 |
> For instance, Seamonkey doesn't have a USE=perl flag. Nor should it have |
| 32 |
> one. |
| 33 |
> |
| 34 |
|
| 35 |
Nice example with USE=perl, thanks! git has that, for instance. Without |
| 36 |
that, `git add -i` won't work, but I still have USE=perl, not |
| 37 |
USE=add_interactive and possibly a bunch of other features depending on |
| 38 |
Perl that would pull it when enabled. |
| 39 |
|
| 40 |
-- |
| 41 |
Georg Rudoy |
Archives