Georg Rudoy posted on Sun, 03 May 2015 17:13:49 +0300 as excerpted:
> 2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.dun...@cox.net>:
>
>> What about a somewhat more generic flag such as newcode?
> Nice idea, thanks! There are a couple of corner cases though.
>
>> newcode would even be generic enough
Georg Rudoy posted on Sun, 03 May 2015 17:04:54 +0300 as excerpted:
> Speaking of llvm, media-libs/mesa has "llvm" use flag. Why should user
> care if it's llvm or whatever?
The local use-description tells the store there:
"Enamble LLVM backend for Gallium3D"
In this case, LLVM is the feature,
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2015-05-03 23:59 UTC.
Removals:
dev-java/jna-posix 2015-04-28 20:44:42 chewi
games-emulation/tuxnes 2015-04-29 21:52:11 mr_bones_
dev-games/libgra
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
2015-05-03 13:51 GMT+03:00 Duncan <1i5t5.dun...@cox.net>:
> What about a somewhat more generic flag such as newcode? Like the bindist
> or minimal flags, this could be global, but with local descriptions very
> strongly recommended. Similarly, like minimal, setting it globally would
> be strongl
2015-05-03 13:19 GMT+03:00 Maxim Koltsov :
> Well, I can see your point. But I don't see any reasonable alternative ---
> this functionality can't be generalized by any name, except "c++14" ---
> that's only thing in common.
>
Yes, exactly.
> Moreover, this is (I hope) a _temporal_ solution, un
2015-05-03 1:30 GMT+03:00 Kent Fredric :
> and python very often *is* saying "Support for python" ( not in, but _for_
> )
>
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 s
Maxim Koltsov posted on Sun, 03 May 2015 13:19:18 +0300 as excerpted:
> this functionality can't be generalized by any name, except "c++14" ---
> that's only thing in common. Moreover, this is (I hope) a _temporal_
> solution, until there's a gcc with needed level of support. And of
> course we ca
2015-05-03 1:30 GMT+03:00 Kent Fredric :
>
> 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_
# Hans de Graaff (3 May 2015)
# dev-ruby/fssm is deprecated by its author and nothing
# in the tree depends on it anymore. Use dev-ruby/listen
# as an alternative. Masked for removal in 30 days.
dev-ruby/fssm
signature.asc
Description: This is a digitally signed message part
10 matches
Mail list logo
