llvm dev - Nov 2013 - [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>

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.

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

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>