"C. Bergström"
2013-Oct-30 01:42 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 10/30/13 08:24 AM, Richard Smith wrote:> > May I humbly propose you create a c++11-development branch > now/later/anytime and let people start using that. In parallel to > that let people know that pieces of the c++11 branch will > potentially start merging Feb 1st 2014. (roughly 3 months from > today). This gives people time to review things before they hit > trunk, test, discuss and experiment in a way that virtual > discussions simply can't flush out. This hopefully won't hurt your > target of the release-after-next using more modern toolchains and > is *hopefully* a win-win in your view. > > > I don't see how this helps anything. We don't /want/ to have the > hassle of some people developing on a branch and some on trunk, so we > would essentially have trunk stagnating and everyone developing on the > branch. And then we'd merge the branch back again. Net result: exactly > the same as if the people who aren't ready for c++11 stick with the > 3.4 release.No its entirely not the same 1) Branch development is very common - I can't imagine *everyone* will use c++11 immediately and it causing some instant stall on trunk if a branch was made 2) As stated before - a branch lets a *real* discussion happen *before* it hits trunk. With any big feature change - isn't it best to be a little conservative instead of potentially break 1st and fix-it-later approach. Right now we're having a virtual discussion about things which may/may not happen. A branch with code is a tangible which can allow *real* testing and feedback. I think it's being worked on independently, but I haven't even seen an updated style guide. I don't even know what's exactly being proposed at this time. "c++11" is still fuzzy... clang/llvm has been around for 10 years?? Will waiting an extra month or doing some work in a branch 1st really kill anyone? Doesn't google and friends already use a branch model for development/test before it's merged.
Chandler Carruth
2013-Oct-30 02:40 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On Tue, Oct 29, 2013 at 6:42 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote:> On 10/30/13 08:24 AM, Richard Smith wrote: > >> >> May I humbly propose you create a c++11-development branch >> now/later/anytime and let people start using that. In parallel to >> that let people know that pieces of the c++11 branch will >> potentially start merging Feb 1st 2014. (roughly 3 months from >> today). This gives people time to review things before they hit >> trunk, test, discuss and experiment in a way that virtual >> discussions simply can't flush out. This hopefully won't hurt your >> target of the release-after-next using more modern toolchains and >> is *hopefully* a win-win in your view. >> >> >> I don't see how this helps anything. We don't /want/ to have the hassle >> of some people developing on a branch and some on trunk, so we would >> essentially have trunk stagnating and everyone developing on the branch. >> And then we'd merge the branch back again. Net result: exactly the same as >> if the people who aren't ready for c++11 stick with the 3.4 release. >> > No its entirely not the same > > 1) Branch development is very common - I can't imagine *everyone* will use > c++11 immediately and it causing some instant stall on trunk if a branch > was made >It is not common in LLVM.> 2) As stated before - a branch lets a *real* discussion happen *before* it > hits trunk. With any big feature change - isn't it best to be a little > conservative instead of potentially break 1st and fix-it-later approach. > > Right now we're having a virtual discussion about things which may/may not > happen. A branch with code is a tangible which can allow *real* testing and > feedback. I think it's being worked on independently, but I haven't even > seen an updated style guide. I don't even know what's exactly being > proposed at this time. "c++11" is still fuzzy... >Many of the folks discussing this and indeed many of the contributors have worked on reasonable size code bases with C++11 features. We also have a sub-project using those C++11 features. I think there is nothing fuzzy and nothing objectionable here. I don't think your objection is significantly concerning, and frankly, the consensus (weighted by contribution to the projects) still seems strongly supportive, and so I'm moving forward.> clang/llvm has been around for 10 years?? Will waiting an extra month or > doing some work in a branch 1st really kill anyone?No, it simply won't happen. That's why we don't use branches often.> Doesn't google and friends already use a branch model for development/test > before it's merged. >Many people maintain branches for internal code that doesn't get contributed (often because it's not useful, or just not ready). But when they go to contribute it, they work to integrate it into the mainline as-if developed against head. Andy's recent work on the support for patching running code etc is a great example. Please don't make this about Google, Apple, or other companies, as it isn't. This is about the LLVM open source project, and what the body of active contributors think the *right* direction for the project is. I think we have some pretty strong agreement thus far: C++11. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/7ddbd67b/attachment.html>
Renato Golin
2013-Oct-30 05:16 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 29 October 2013 19:40, Chandler Carruth <chandlerc at google.com> wrote:> Please don't make this about Google, Apple, or other companies, as it > isn't. This is about the LLVM open source project, and what the body of > active contributors think the *right* direction for the project is. I think > we have some pretty strong agreement thus far: C++11. >+1 --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/928b2b94/attachment.html>
Joshua Cranmer 🐧
2013-Oct-30 13:45 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 10/29/2013 8:42 PM, "C. Bergström" wrote:> On 10/30/13 08:24 AM, Richard Smith wrote: >> >> May I humbly propose you create a c++11-development branch >> now/later/anytime and let people start using that. In parallel to >> that let people know that pieces of the c++11 branch will >> potentially start merging Feb 1st 2014. (roughly 3 months from >> today). This gives people time to review things before they hit >> trunk, test, discuss and experiment in a way that virtual >> discussions simply can't flush out. This hopefully won't hurt your >> target of the release-after-next using more modern toolchains and >> is *hopefully* a win-win in your view. >> >> >> I don't see how this helps anything. We don't /want/ to have the >> hassle of some people developing on a branch and some on trunk, so we >> would essentially have trunk stagnating and everyone developing on >> the branch. And then we'd merge the branch back again. Net result: >> exactly the same as if the people who aren't ready for c++11 stick >> with the 3.4 release. > No its entirely not the same > > 1) Branch development is very common - I can't imagine *everyone* will > use c++11 immediately and it causing some instant stall on trunk if a > branch was made > 2) As stated before - a branch lets a *real* discussion happen > *before* it hits trunk. With any big feature change - isn't it best to > be a little conservative instead of potentially break 1st and > fix-it-later approach.The problem is that retrofitting code to use C++11 features is extremely invasive into a codebase, and (depending on the feature being changed) has a high risk of making many patches fail to apply. A C++11 branch isn't going to work: either you will have to transplant patches from the C++11 development branch to mainline trunk (depending on the patch, this ranges from "maybe easy" to "impossible") or go through cumbersome merges on a regular basis to keep the C++11 branch up-to-date. So everyone who wants to use C++11 in their code is left struggling in pain for development. At the same time, how will this find bugs? The people who track the C++11 development branch would be the people who don't object to using C++11 in the first place, and they are going to be the ones who don't have the problem. The people who may have the problems are going to be following trunk, and, with a C++1 development branch, they're not going to know about problems until a large, unbackoutable, nasty merge lands on trunk. All you are doing is delaying the pain point. If you *really* want to to give people time to handle the issues, what you do is you make C++11 support mandatory in the build system but don't use any [non-polyfilled] features yet. There is just enough C++11 code in the tree that would be enabled to flag broken setups, and this is a small patch that could be undone without much pain if the problems discovered are unfixable. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist
Apparently Analagous Threads
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers