1 |
2014-02-26 12:35 GMT+04:00 Dirkjan Ochtman <djc@g.o>: |
2 |
> On Wed, Feb 26, 2014 at 9:26 AM, Georg Rudoy <0xd34df00d@×××××.com> wrote: |
3 |
>> I'm currently considering using C++14 in my project, particularly |
4 |
>> features that aren't supported by gcc 4.8 and are barely supported by |
5 |
>> 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. |
6 |
>> Thus I wonder how bad is actually depending on recent clang in |
7 |
>> ebuilds? |
8 |
> |
9 |
> If you want to do that, it's not a problem with me. That said, I |
10 |
> probably wouldn't install packages that wanted to pull in a whole |
11 |
> different toolchain unless I wanted them really badly (but on machines |
12 |
> where I already have clang installed, I might not even notice). |
13 |
> |
14 |
> I'd say there's value in staying close to where the community's at, if |
15 |
> you actually want your software to be used. If you don't care that |
16 |
> much about your software being used by other people, nobody can stop |
17 |
> you. |
18 |
|
19 |
I thought about some policy-related problems. Good if there aren't any. |
20 |
|
21 |
Thanks for the opinion. Depending strictly on clang is more like a |
22 |
temporary measure until gcc catches up, which I hope will happen fast |
23 |
enough. In this case I'll also probably stick with just introducing |
24 |
the dependency in newer, probably even unpackaged modules so everyone |
25 |
will be able to use what's already considered to be somewhat stable |
26 |
and solid part of the app with "standard" gcc. |
27 |
|
28 |
-- |
29 |
Georg Rudoy |