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