Renato Golin
2013-Nov-06 08:10 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 5 November 2013 10:12, <dag at cray.com> wrote:> I'm fine with the general plan but I do want to see a longer notice > period for toolchain changes on trunk. 1-2 months is too short. >I may be wrong, but I think the final consensus was: for every new change, warn on (at least) one previous release as when the changes go live. If I'm mistaken, this is still my opinion on the matter. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131106/adc01dfd/attachment.html>
David Chisnall
2013-Nov-06 09:07 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 6 Nov 2013, at 08:10, Renato Golin <renato.golin at linaro.org> wrote:> On 5 November 2013 10:12, <dag at cray.com> wrote: >> I'm fine with the general plan but I do want to see a longer notice >> period for toolchain changes on trunk. 1-2 months is too short. > > I may be wrong, but I think the final consensus was: for every new change, warn on (at least) one previous release as when the changes go live. > > If I'm mistaken, this is still my opinion on the matter.I think his point was that we encourage out-of-tree projects to follow ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14) feature Z means that people may start using that feature in ToT as soon as the x.y release is branched (which may be even before the announcement that x.(y+1) will use the new feature). If the new feature requires out-of-tree LLVM users to upgrade their toolchains then we may only be giving them a month or less warning, even if we are giving downstream packagers 6 months. Given how hard we already make it for people to follow ToT for out-of-tree projects (and how much we shout at them when they don't), I'd rather that we didn't make it any harder. And with my downstream packager hat on, it's frustrating that we don't make it easier, because we end up having to make sure that it's possible to install half a dozen different versions of LLVM simultaneously because there are always some projects that depend on an old one and only have the manpower to handle the API churn every few releases - I think we've now finally got rid of the ones that depend on LLVM 2.6, but 2.8 is still quite popular. David [1] We make their life very hard by introducing new APIs long before we document them. For example, we still don't have adequate documentation of the new attributes classes, but that's a separate rant.
dag at cray.com
2013-Nov-06 17:17 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:>> I may be wrong, but I think the final consensus was: for every new >> change, warn on (at least) one previous release as when the changes >> go live. >> >> If I'm mistaken, this is still my opinion on the matter. > > I think his point was that we encourage out-of-tree projects to follow > ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14) > feature Z means that people may start using that feature in ToT as > soon as the x.y release is branched (which may be even before the > announcement that x.(y+1) will use the new feature).Yep.> If the new feature requires out-of-tree LLVM users to upgrade their > toolchains then we may only be giving them a month or less warning, > even if we are giving downstream packagers 6 months.Correct. That's not enough warning.> Given how hard we already make it for people to follow ToT for > out-of-tree projects (and how much we shout at them when they don't), > I'd rather that we didn't make it any harder. > > And with my downstream packager hat on, it's frustrating that we don't > make it easier, because we end up having to make sure that it's > possible to install half a dozen different versions of LLVM > simultaneously because there are always some projects that depend on > an old one and only have the manpower to handle the API churn every > few releases - I think we've now finally got rid of the ones that > depend on LLVM 2.6, but 2.8 is still quite popular.Thank you for that. You've summarize all of the issues with the current development and release practice quite well.> David > > [1] We make their life very hard by introducing new APIs long before > we document them. For example, we still don't have adequate > documentation of the new attributes classes, but that's a separate > rant.Yes! -David
Chandler Carruth
2013-Nov-07 09:38 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On Wed, Nov 6, 2013 at 1:07 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk>wrote:> I think his point was that we encourage out-of-tree projects to follow > ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14) > feature Z means that people may start using that feature in ToT as soon as > the x.y release is branched (which may be even before the announcement that > x.(y+1) will use the new feature). >So, this email discussion, and the summary email I sent to the dev lists is the announcement. So there will be some time for folks to do this. I think *no* warning is too little warning, but I don't think that's what we're talking about here. That said, I completely agree that this is a relatively aggressive schedule for ToT. I also like that you draw analogy to the API changes which I view is quite similar.> > If the new feature requires out-of-tree LLVM users to upgrade their > toolchains then we may only be giving them a month or less warning, even if > we are giving downstream packagers 6 months. > > Given how hard we already make it for people to follow ToT for out-of-tree > projects (and how much we shout at them when they don't), I'd rather that > we didn't make it any harder. >I actually am not sure about the shouting at people when they don't follow ToT with their out-of-tree projects. I see a lot more pressure for folks to do their work in the open than to do closed source work against ToT. I think that's actually reasonably healthy for the project. The (very significant) overhead of tracking ToT or even release-to-release changes (and the workarounds for the bugs that never get a patch release) tend to heavily incentivize people to contribute back their changes. One of the primary benefits of pushing changes back into the open source repo is that now API updates are done for you. So, *if* you need to maintain an out of tree project (and there are a bunch of really good reasons to do this!), you end up paying a steep tax to track *either* ToT or each release. In the case of tracking ToT, I think that the cost of dealing with API changes is tremendously higher than switching to a C++11 supporting toolchain. (Of course, in aggregate. Each API change may be cheaper, but they come in such frequency that the total cost seems likely to dwarf that of the toolchain rev.)> > And with my downstream packager hat on, it's frustrating that we don't > make it easier, because we end up having to make sure that it's possible to > install half a dozen different versions of LLVM simultaneously because > there are always some projects that depend on an old one and only have the > manpower to handle the API churn every few releases - I think we've now > finally got rid of the ones that depend on LLVM 2.6, but 2.8 is still quite > popular. >Again, I think the API issues are far and away the dominant concerns here. I'm not trying to say your concern is invalid; while I would pick a different tradeoff, its still at most a tradeoff and reasonable people can disagree about the right tradeoff to make. However, even from this perspective, I feel like the cost and tradeoffs you face with APIs dwarf those you face with us starting to use C++11. It seems like if this is what we should be optimizing for, we should start by fixing the API churn issue and then look at other sources of churn. However, thus far the project has chosen *not* to optimize for this, and instead to optimize for in-tree efforts. Using C++11 seems like icing on this cake. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131107/f1708c37/attachment.html>
Maybe Matching 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