| 1 |
Hey Jan,
|
| 2 |
|
| 3 |
Jan Kundrát <jkt@g.o> writes:
|
| 4 |
|
| 5 |
> This perspective is interesting (and I admit that I tend to like it) -- |
| 6 |
> considering packages which won't build with C++11 to be buggy. |
| 7 |
> |
| 8 |
> I'm worried by the cost of such a policy, though, because we would |
| 9 |
> suddenly have to patch some unknown amount of software (and I'm pretty |
| 10 |
> sure some upstreams would reject these patches anyway). If we were an |
| 11 |
> enterprise distro with binary compatibility requirements, we would |
| 12 |
> also have to worry about that and either assume that the ABI changes |
| 13 |
> are non-issue in real world, or provide two versions of all C++ |
| 14 |
> libraries. I tried to check how RHEL7 will deal with it, but I wasn't |
| 15 |
> able to find any information about that. It also seems that Fedora |
| 16 |
> hasn't addressed this yet, either. |
| 17 |
> |
| 18 |
> Either way, it is reasonable to assume that some users would like to |
| 19 |
> build their own software and link it with system libraries. It is not |
| 20 |
> reasonable to force these users to build in the C++11 mode, IMHO. |
| 21 |
|
| 22 |
I'd like to make an analogy to the version bump of gcc[1]. We (gentoo)
|
| 23 |
decide to support c++11 officially or not. If so, open a tracker bug to
|
| 24 |
push it globally. If not, patch lldb to support non-c++11, or leave it
|
| 25 |
up to the user to fiddle with the CXXFLAGS, where we only point the user
|
| 26 |
by to proper docs.
|
| 27 |
|
| 28 |
There is no problem to introduce a new USE flag for a new ABI. I am
|
| 29 |
concerned with too many ABIs for an average ebuild keeper to maintain.
|
| 30 |
|
| 31 |
Benda
|
| 32 |
|
| 33 |
1. https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.8 |
Archives