| 1 |
On Wednesday, 18 December 2013 18:05:46 CEST, "C. Bergström" wrote: |
| 2 |
> If moving to C++11 - Isn't that considered just part of the |
| 3 |
> work along the path? There's some clang tools to help with the |
| 4 |
> migration, but I don't think anyone expects it to be zero work. |
| 5 |
> The flag is just a way to a) enable building programs that can |
| 6 |
> be built with c++11 b) flush out the culprits in the cases it |
| 7 |
> can't be. If (b) is a bug - how else to find it easily? |
| 8 |
|
| 9 |
This perspective is interesting (and I admit that I tend to like it) -- |
| 10 |
considering packages which won't build with C++11 to be buggy. |
| 11 |
|
| 12 |
I'm worried by the cost of such a policy, though, because we would suddenly |
| 13 |
have to patch some unknown amount of software (and I'm pretty sure some |
| 14 |
upstreams would reject these patches anyway). If we were an enterprise |
| 15 |
distro with binary compatibility requirements, we would also have to worry |
| 16 |
about that and either assume that the ABI changes are non-issue in real |
| 17 |
world, or provide two versions of all C++ libraries. I tried to check how |
| 18 |
RHEL7 will deal with it, but I wasn't able to find any information about |
| 19 |
that. It also seems that Fedora hasn't addressed this yet, either. |
| 20 |
|
| 21 |
Either way, it is reasonable to assume that some users would like to build |
| 22 |
their own software and link it with system libraries. It is not reasonable |
| 23 |
to force these users to build in the C++11 mode, IMHO. |
| 24 |
|
| 25 |
Cheers, |
| 26 |
Jan |
Archives