llvm dev - Feb 2015 - [LLVMdev] [lldb-dev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

I have moved onto the next phase and committed r229185, which makes VS2013 our
minimum version. I will revert if issues arise, and we can rinse and repeat as
necessary.

Once it sticks for a bit I’ll update the docs too.

-Chris
> On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> I agree with Aaron, this should not be a blocker because the workaround is
simple. I'm also not opposed to raising the minimum CMake version all the
way to 3.0. CMake 3 is 6 months old and CMake 3.1 is already out.
> 
> I think most (if not all) our internal users are on 3.0 now, and those that
may not be are either on old branches of LLVM or have no excuse not to update. I
can start a separate thread with that proposal.
> 
> -Chris
> 
> Sent from my iPad
> 
>> On Feb 9, 2015, at 7:44 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>> 
>>> On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell <gregbedwell at
gmail.com> wrote:
>>> We've just encountered an issue with ninja and VS2013 when
using versions of
>>> CMake prior to 2.8.12.1.  This isn't a combination that we
typically use so
>>> we've not run into it previously in our own builds.  It
isn't specifically
>>> tied to upgrading the minimum version as it's a problem that
already exists
>>> but I figure we'll hit it sooner or later on one of the bots as
people start
>>> to use 2013 so best to deal with it sooner.  Essentially, when
building any
>>> configuration through ninja with debug data enabled with anything
more than
>>> -j1 we'll hit an error like:
>>> 
>>> C:\work\public_svn\llvm\lib\Support\APInt.cpp : fatal error C1041:
cannot
>>> open program database
>>>
'c:\work\public_svn\build-vs2013-native-ninja\lib\llvmsupport.pdb'; if
>>> multiple CL.EXE write to the same .PDB file, please use /FS
>>> 
>>> Here's the relevant CMake tracker which shows the fix going
into 2.8.12.1:
>>> http://www.cmake.org/Bug/view.php?id=14492
>>> 
>>> I think our options are to either require CMake 2.8.12.1 for
VS2013/ninja
>>> builds (but I don't know how feasible this is) or we can put
our own
>>> workaround into our CMakelists to push the /FS switch when using
Ninja and
>>> Visual Studio, unless someone has any better ideas?
>>> 
>>> Any thoughts?  Is this a blocker for updating the minimum version?
>> 
>> I'm not certain I see it as a blocker since upgrading CMake should
not
>> be too difficult (2.8.12.1 was released in Nov 2013). Whether we want
>> to require 2.8.12.1 is a different ball of wax, but for just the Ninja
>> + MSVC build, I don't think that's too onerous (then again, I
don't
>> use Ninja for my builds, either).
>> 
>> ~Aaron
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Please wait. I'll revert it for now. I'll reland it when I am ready.

2015-02-14 8:27 GMT+09:00 Chris Bieneman <beanz at
apple.com>:
> I have moved onto the next phase and committed r229185, which makes VS2013
our minimum version. I will revert if issues arise, and we can rinse and repeat
as necessary.
>
> Once it sticks for a bit I’ll update the docs too.
>
> -Chris
>
>> On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at apple.com>
wrote:
>>
>> I agree with Aaron, this should not be a blocker because the workaround
is simple. I'm also not opposed to raising the minimum CMake version all the
way to 3.0. CMake 3 is 6 months old and CMake 3.1 is already out.
>>
>> I think most (if not all) our internal users are on 3.0 now, and those
that may not be are either on old branches of LLVM or have no excuse not to
update. I can start a separate thread with that proposal.
>>
>> -Chris
>>
>> Sent from my iPad
>>
>>> On Feb 9, 2015, at 7:44 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>>>
>>>> On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell <gregbedwell at
gmail.com> wrote:
>>>> We've just encountered an issue with ninja and VS2013 when
using versions of
>>>> CMake prior to 2.8.12.1.  This isn't a combination that we
typically use so
>>>> we've not run into it previously in our own builds.  It
isn't specifically
>>>> tied to upgrading the minimum version as it's a problem
that already exists
>>>> but I figure we'll hit it sooner or later on one of the
bots as people start
>>>> to use 2013 so best to deal with it sooner.  Essentially, when
building any
>>>> configuration through ninja with debug data enabled with
anything more than
>>>> -j1 we'll hit an error like:
>>>>
>>>> C:\work\public_svn\llvm\lib\Support\APInt.cpp : fatal error
C1041: cannot
>>>> open program database
>>>>
'c:\work\public_svn\build-vs2013-native-ninja\lib\llvmsupport.pdb'; if
>>>> multiple CL.EXE write to the same .PDB file, please use /FS
>>>>
>>>> Here's the relevant CMake tracker which shows the fix going
into 2.8.12.1:
>>>> http://www.cmake.org/Bug/view.php?id=14492
>>>>
>>>> I think our options are to either require CMake 2.8.12.1 for
VS2013/ninja
>>>> builds (but I don't know how feasible this is) or we can
put our own
>>>> workaround into our CMakelists to push the /FS switch when
using Ninja and
>>>> Visual Studio, unless someone has any better ideas?
>>>>
>>>> Any thoughts?  Is this a blocker for updating the minimum
version?
>>>
>>> I'm not certain I see it as a blocker since upgrading CMake
should not
>>> be too difficult (2.8.12.1 was released in Nov 2013). Whether we
want
>>> to require 2.8.12.1 is a different ball of wax, but for just the
Ninja
>>> + MSVC build, I don't think that's too onerous (then again,
I don't
>>> use Ninja for my builds, either).
>>>
>>> ~Aaron
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Learned this the hard way after spending a few hours with the help of
chandlerc to diagnose a problem.  The TL;DR is that template aliases are
NOT ready for prime time.  Please don't use them on any platform until we
raise the minimum version to VS 2015.

On Fri Feb 13 2015 at 4:47:07 PM NAKAMURA Takumi <geek4civic at gmail.com>
wrote:
> Please wait. I'll revert it for now. I'll reland it when I am
ready.
>
> 2015-02-14 8:27 GMT+09:00 Chris Bieneman <beanz at apple.com>:
> > I have moved onto the next phase and committed r229185, which makes
> VS2013 our minimum version. I will revert if issues arise, and we can rinse
> and repeat as necessary.
> >
> > Once it sticks for a bit I’ll update the docs too.
> >
> > -Chris
> >
> >> On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at
apple.com> wrote:
> >>
> >> I agree with Aaron, this should not be a blocker because the
workaround
> is simple. I'm also not opposed to raising the minimum CMake version
all
> the way to 3.0. CMake 3 is 6 months old and CMake 3.1 is already out.
> >>
> >> I think most (if not all) our internal users are on 3.0 now, and
those
> that may not be are either on old branches of LLVM or have no excuse not to
> update. I can start a separate thread with that proposal.
> >>
> >> -Chris
> >>
> >> Sent from my iPad
> >>
> >>> On Feb 9, 2015, at 7:44 AM, Aaron Ballman <aaron at
aaronballman.com>
> wrote:
> >>>
> >>>> On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell
<gregbedwell at gmail.com>
> wrote:
> >>>> We've just encountered an issue with ninja and VS2013
when using
> versions of
> >>>> CMake prior to 2.8.12.1.  This isn't a combination
that we typically
> use so
> >>>> we've not run into it previously in our own builds. 
It isn't
> specifically
> >>>> tied to upgrading the minimum version as it's a
problem that already
> exists
> >>>> but I figure we'll hit it sooner or later on one of
the bots as
> people start
> >>>> to use 2013 so best to deal with it sooner.  Essentially,
when
> building any
> >>>> configuration through ninja with debug data enabled with
anything
> more than
> >>>> -j1 we'll hit an error like:
> >>>>
> >>>> C:\work\public_svn\llvm\lib\Support\APInt.cpp : fatal
error C1041:
> cannot
> >>>> open program database
> >>>>
'c:\work\public_svn\build-vs2013-native-ninja\lib\llvmsupport.pdb';
> if
> >>>> multiple CL.EXE write to the same .PDB file, please use
/FS
> >>>>
> >>>> Here's the relevant CMake tracker which shows the fix
going into
> 2.8.12.1:
> >>>> http://www.cmake.org/Bug/view.php?id=14492
> >>>>
> >>>> I think our options are to either require CMake 2.8.12.1
for
> VS2013/ninja
> >>>> builds (but I don't know how feasible this is) or we
can put our own
> >>>> workaround into our CMakelists to push the /FS switch when
using
> Ninja and
> >>>> Visual Studio, unless someone has any better ideas?
> >>>>
> >>>> Any thoughts?  Is this a blocker for updating the minimum
version?
> >>>
> >>> I'm not certain I see it as a blocker since upgrading
CMake should not
> >>> be too difficult (2.8.12.1 was released in Nov 2013). Whether
we want
> >>> to require 2.8.12.1 is a different ball of wax, but for just
the Ninja
> >>> + MSVC build, I don't think that's too onerous (then
again, I don't
> >>> use Ninja for my builds, either).
> >>>
> >>> ~Aaron
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/beaafd2d/attachment.html>

Can you please add a note about this to the Coding Standards doc? It would be
nice to have this preserved along with the list of features we allow.

Thanks,
-Chris


> On Feb 16, 2015, at 12:59 AM, Zachary Turner <zturner at google.com>
wrote:
> 
> Learned this the hard way after spending a few hours with the help of
chandlerc to diagnose a problem.  The TL;DR is that template aliases are NOT
ready for prime time.  Please don't use them on any platform until we raise
the minimum version to VS 2015.
> 
>> On Fri Feb 13 2015 at 4:47:07 PM NAKAMURA Takumi <geek4civic at
gmail.com> wrote:
>> Please wait. I'll revert it for now. I'll reland it when I am
ready.
>> 
>> 2015-02-14 8:27 GMT+09:00 Chris Bieneman <beanz at apple.com>:
>> > I have moved onto the next phase and committed r229185, which
makes VS2013 our minimum version. I will revert if issues arise, and we can
rinse and repeat as necessary.
>> >
>> > Once it sticks for a bit I’ll update the docs too.
>> >
>> > -Chris
>> >
>> >> On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at
apple.com> wrote:
>> >>
>> >> I agree with Aaron, this should not be a blocker because the
workaround is simple. I'm also not opposed to raising the minimum CMake
version all the way to 3.0. CMake 3 is 6 months old and CMake 3.1 is already
out.
>> >>
>> >> I think most (if not all) our internal users are on 3.0 now,
and those that may not be are either on old branches of LLVM or have no excuse
not to update. I can start a separate thread with that proposal.
>> >>
>> >> -Chris
>> >>
>> >> Sent from my iPad
>> >>
>> >>> On Feb 9, 2015, at 7:44 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>> >>>
>> >>>> On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell
<gregbedwell at gmail.com> wrote:
>> >>>> We've just encountered an issue with ninja and
VS2013 when using versions of
>> >>>> CMake prior to 2.8.12.1.  This isn't a combination
that we typically use so
>> >>>> we've not run into it previously in our own
builds.  It isn't specifically
>> >>>> tied to upgrading the minimum version as it's a
problem that already exists
>> >>>> but I figure we'll hit it sooner or later on one
of the bots as people start
>> >>>> to use 2013 so best to deal with it sooner. 
Essentially, when building any
>> >>>> configuration through ninja with debug data enabled
with anything more than
>> >>>> -j1 we'll hit an error like:
>> >>>>
>> >>>> C:\work\public_svn\llvm\lib\Support\APInt.cpp : fatal
error C1041: cannot
>> >>>> open program database
>> >>>>
'c:\work\public_svn\build-vs2013-native-ninja\lib\llvmsupport.pdb'; if
>> >>>> multiple CL.EXE write to the same .PDB file, please
use /FS
>> >>>>
>> >>>> Here's the relevant CMake tracker which shows the
fix going into 2.8.12.1:
>> >>>> http://www.cmake.org/Bug/view.php?id=14492
>> >>>>
>> >>>> I think our options are to either require CMake
2.8.12.1 for VS2013/ninja
>> >>>> builds (but I don't know how feasible this is) or
we can put our own
>> >>>> workaround into our CMakelists to push the /FS switch
when using Ninja and
>> >>>> Visual Studio, unless someone has any better ideas?
>> >>>>
>> >>>> Any thoughts?  Is this a blocker for updating the
minimum version?
>> >>>
>> >>> I'm not certain I see it as a blocker since upgrading
CMake should not
>> >>> be too difficult (2.8.12.1 was released in Nov 2013).
Whether we want
>> >>> to require 2.8.12.1 is a different ball of wax, but for
just the Ninja
>> >>> + MSVC build, I don't think that's too onerous
(then again, I don't
>> >>> use Ninja for my builds, either).
>> >>>
>> >>> ~Aaron
>> >>
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >
>> >
>> > _______________________________________________
>> > lldb-dev mailing list
>> > lldb-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/83e70bcd/attachment.html>

Takumi,

Can you please provide an update? We've been working on this change for
months, if there are blocking issues we need to know what they are.

Thanks,
-Chris


> On Feb 13, 2015, at 4:40 PM, NAKAMURA Takumi <geek4civic at
gmail.com> wrote:
> 
> Please wait. I'll revert it for now. I'll reland it when I am
ready.
> 
> 2015-02-14 8:27 GMT+09:00 Chris Bieneman <beanz at apple.com>:
>> I have moved onto the next phase and committed r229185, which makes
VS2013 our minimum version. I will revert if issues arise, and we can rinse and
repeat as necessary.
>> 
>> Once it sticks for a bit I’ll update the docs too.
>> 
>> -Chris
>> 
>>> On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at
apple.com> wrote:
>>> 
>>> I agree with Aaron, this should not be a blocker because the
workaround is simple. I'm also not opposed to raising the minimum CMake
version all the way to 3.0. CMake 3 is 6 months old and CMake 3.1 is already
out.
>>> 
>>> I think most (if not all) our internal users are on 3.0 now, and
those that may not be are either on old branches of LLVM or have no excuse not
to update. I can start a separate thread with that proposal.
>>> 
>>> -Chris
>>> 
>>> Sent from my iPad
>>> 
>>>>> On Feb 9, 2015, at 7:44 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>>>>> 
>>>>> On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell
<gregbedwell at gmail.com> wrote:
>>>>> We've just encountered an issue with ninja and VS2013
when using versions of
>>>>> CMake prior to 2.8.12.1.  This isn't a combination that
we typically use so
>>>>> we've not run into it previously in our own builds.  It
isn't specifically
>>>>> tied to upgrading the minimum version as it's a problem
that already exists
>>>>> but I figure we'll hit it sooner or later on one of the
bots as people start
>>>>> to use 2013 so best to deal with it sooner.  Essentially,
when building any
>>>>> configuration through ninja with debug data enabled with
anything more than
>>>>> -j1 we'll hit an error like:
>>>>> 
>>>>> C:\work\public_svn\llvm\lib\Support\APInt.cpp : fatal error
C1041: cannot
>>>>> open program database
>>>>>
'c:\work\public_svn\build-vs2013-native-ninja\lib\llvmsupport.pdb'; if
>>>>> multiple CL.EXE write to the same .PDB file, please use /FS
>>>>> 
>>>>> Here's the relevant CMake tracker which shows the fix
going into 2.8.12.1:
>>>>> http://www.cmake.org/Bug/view.php?id=14492
>>>>> 
>>>>> I think our options are to either require CMake 2.8.12.1
for VS2013/ninja
>>>>> builds (but I don't know how feasible this is) or we
can put our own
>>>>> workaround into our CMakelists to push the /FS switch when
using Ninja and
>>>>> Visual Studio, unless someone has any better ideas?
>>>>> 
>>>>> Any thoughts?  Is this a blocker for updating the minimum
version?
>>>> 
>>>> I'm not certain I see it as a blocker since upgrading CMake
should not
>>>> be too difficult (2.8.12.1 was released in Nov 2013). Whether
we want
>>>> to require 2.8.12.1 is a different ball of wax, but for just
the Ninja
>>>> + MSVC build, I don't think that's too onerous (then
again, I don't
>>>> use Ninja for my builds, either).
>>>> 
>>>> ~Aaron
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

+ Chandler

Ok… What’s going on here?

I see Takumi re-landed the patches, but there have been a lot of changes that
came in yesterday that go against the plan for rolling this out.

The original plan (as proposed by Chandler) was to wait a week after landing the
CMake change before updating the documentation and allowing new C++11 features.
This gives adequate time for people who may have missed this thread to adjust.

We now have uses of new C++11 features that aren’t supported by VS2012 littered
around, which makes backing this change out far less trivial.

What is the plan now?

-Chris
> On Feb 16, 2015, at 8:27 AM, Benjamin Kramer <benny.kra at gmail.com>
wrote:
> 
>> 
>> On 16.02.2015, at 17:02, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>> 
>> Takumi,
>> 
>> Can you please provide an update? We've been working on this change
for months, if there are blocking issues we need to know what they are.
> 
> In case you didn't see it, the patch was relanded yesterday and
Takumi's bots are updated. I also updated the docs yesterday and a ton of
cruft that accumulated to support MSVC 2012 was removed, there's no going
back now ;)
> 
> What's left is updating our CodingStandards to properly reflect the
supported C++11 features, as we've seen with the template aliases
Microsoft's docs can't be trusted without manual verification. There are
also some MSVC 2012 bots left on lab.llvm.org <http://lab.llvm.org/> that
fail at the cmake stage now, 'lldb-x86-windows-msvc' and
'lld-x86_64-win7'. Not sure what to do about them
> 
> - Ben
> 
>>> On Feb 13, 2015, at 4:40 PM, NAKAMURA Takumi <geek4civic at
gmail.com> wrote:
>>> 
>>> Please wait. I'll revert it for now. I'll reland it when I
am ready.
>>> 
>>> 2015-02-14 8:27 GMT+09:00 Chris Bieneman <beanz at
apple.com>:
>>>> I have moved onto the next phase and committed r229185, which
makes VS2013 our minimum version. I will revert if issues arise, and we can
rinse and repeat as necessary.
>>>> 
>>>> Once it sticks for a bit I’ll update the docs too.
>>>> 
>>>> -Chris
>>>> 
>>>>> On Feb 9, 2015, at 10:07 AM, Chris Bieneman <beanz at
apple.com> wrote:
>>>>> 
>>>>> I agree with Aaron, this should not be a blocker because
the workaround is simple. I'm also not opposed to raising the minimum CMake
version all the way to 3.0. CMake 3 is 6 months old and CMake 3.1 is already
out.
>>>>> 
>>>>> I think most (if not all) our internal users are on 3.0
now, and those that may not be are either on old branches of LLVM or have no
excuse not to update. I can start a separate thread with that proposal.
>>>>> 
>>>>> -Chris
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>>>> On Feb 9, 2015, at 7:44 AM, Aaron Ballman <aaron
at aaronballman.com> wrote:
>>>>>>> 
>>>>>>> On Mon, Feb 9, 2015 at 8:36 AM, Greg Bedwell
<gregbedwell at gmail.com> wrote:
>>>>>>> We've just encountered an issue with ninja and
VS2013 when using versions of
>>>>>>> CMake prior to 2.8.12.1.  This isn't a
combination that we typically use so
>>>>>>> we've not run into it previously in our own
builds.  It isn't specifically
>>>>>>> tied to upgrading the minimum version as it's a
problem that already exists
>>>>>>> but I figure we'll hit it sooner or later on
one of the bots as people start
>>>>>>> to use 2013 so best to deal with it sooner. 
Essentially, when building any
>>>>>>> configuration through ninja with debug data enabled
with anything more than
>>>>>>> -j1 we'll hit an error like:
>>>>>>> 
>>>>>>> C:\work\public_svn\llvm\lib\Support\APInt.cpp :
fatal error C1041: cannot
>>>>>>> open program database
>>>>>>>
'c:\work\public_svn\build-vs2013-native-ninja\lib\llvmsupport.pdb'; if
>>>>>>> multiple CL.EXE write to the same .PDB file, please
use /FS
>>>>>>> 
>>>>>>> Here's the relevant CMake tracker which shows
the fix going into 2.8.12.1:
>>>>>>> http://www.cmake.org/Bug/view.php?id=14492
>>>>>>> 
>>>>>>> I think our options are to either require CMake
2.8.12.1 for VS2013/ninja
>>>>>>> builds (but I don't know how feasible this is)
or we can put our own
>>>>>>> workaround into our CMakelists to push the /FS
switch when using Ninja and
>>>>>>> Visual Studio, unless someone has any better ideas?
>>>>>>> 
>>>>>>> Any thoughts?  Is this a blocker for updating the
minimum version?
>>>>>> 
>>>>>> I'm not certain I see it as a blocker since
upgrading CMake should not
>>>>>> be too difficult (2.8.12.1 was released in Nov 2013).
Whether we want
>>>>>> to require 2.8.12.1 is a different ball of wax, but for
just the Ninja
>>>>>> + MSVC build, I don't think that's too onerous
(then again, I don't
>>>>>> use Ninja for my builds, either).
>>>>>> 
>>>>>> ~Aaron
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
<http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/af0c5d26/attachment.html>

On Mon, Feb 16, 2015 at 1:22 PM, Chris Bieneman <beanz at apple.com>
wrote:
> + Chandler
>
> Ok… What’s going on here?
>
> I see Takumi re-landed the patches, but there have been a lot of changes
> that came in yesterday that go against the plan for rolling this out.
>
> The original plan (as proposed by Chandler) was to wait a week after
landing
> the CMake change before updating the documentation and allowing new C++11
> features. This gives adequate time for people who may have missed this
> thread to adjust.
Once the CMake changes went live, anyone who was still on MSVC 2012
could no longer build, regardless. Waiting a week before landing
changes doesn't make that situation different for those users. I was
under the impression that the week-long embargo was for the docs only,
and it was to give us time to stabilize bots as-needed while finding
out what works and does not work with MSVC 2013 in practice.
> We now have uses of new C++11 features that aren’t supported by VS2012
> littered around, which makes backing this change out far less trivial.
>
> What is the plan now?
I believe the plan is to continue ripping out MSVC 2012 (and earlier)
compatibility to determine the base feature set that's valid to use.
For instance, my testing still shows that MSVC 2013 does not
synthesize move constructors properly, and so a lot of those hacks
must remain in place. However, it appears that = delete and explicit
operator support are sufficient to add to the set of working
items.
>From this, we can update the documentation.
~Aaron

The plan as stated was:

1) Loop in cfe-dev and lldb-dev (Done!)
2) Wait until this email fully circulates in digests and LLVM Weekly so that
everyone who has an objection can voice it
3) If there are no objections, Commit a change to the CMake build which errors
on old MSVC versions
4) Revert and fix buildbots
5) Repeat 3 & 4 until no issues
6) Once the change is live for a week with no issues, update the documentation
to reflect the minimum required MSVC version as 2013

This really doesn’t make sense if we are landing changes requiring MSVC 2013
between steps 3&5. Reverting as needed now that we have a stack of changes
that is piling up isn’t really viable anymore.

So I assume the new plan to just make anyone using MSVC update or they can’t
build anymore.

-Chris
> On Feb 16, 2015, at 10:32 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
> 
> On Mon, Feb 16, 2015 at 1:22 PM, Chris Bieneman <beanz at apple.com>
wrote:
>> + Chandler
>> 
>> Ok… What’s going on here?
>> 
>> I see Takumi re-landed the patches, but there have been a lot of
changes
>> that came in yesterday that go against the plan for rolling this out.
>> 
>> The original plan (as proposed by Chandler) was to wait a week after
landing
>> the CMake change before updating the documentation and allowing new
C++11
>> features. This gives adequate time for people who may have missed this
>> thread to adjust.
> 
> Once the CMake changes went live, anyone who was still on MSVC 2012
> could no longer build, regardless. Waiting a week before landing
> changes doesn't make that situation different for those users. I was
> under the impression that the week-long embargo was for the docs only,
> and it was to give us time to stabilize bots as-needed while finding
> out what works and does not work with MSVC 2013 in practice.
> 
>> We now have uses of new C++11 features that aren’t supported by VS2012
>> littered around, which makes backing this change out far less trivial.
>> 
>> What is the plan now?
> 
> I believe the plan is to continue ripping out MSVC 2012 (and earlier)
> compatibility to determine the base feature set that's valid to use.
> For instance, my testing still shows that MSVC 2013 does not
> synthesize move constructors properly, and so a lot of those hacks
> must remain in place. However, it appears that = delete and explicit
> operator support are sufficient to add to the set of working items.
> From this, we can update the documentation.
> 
> ~Aaron

On Mon, Feb 16, 2015 at 1:37 PM, Chris Bieneman <beanz at apple.com>
wrote:
> The plan as stated was:
>
> 1) Loop in cfe-dev and lldb-dev (Done!)
> 2) Wait until this email fully circulates in digests and LLVM Weekly so
that everyone who has an objection can voice it
> 3) If there are no objections, Commit a change to the CMake build which
errors on old MSVC versions
> 4) Revert and fix buildbots
> 5) Repeat 3 & 4 until no issues
It's my understanding that we're past step 5 currently, and waiting to
do step 6.
> 6) Once the change is live for a week with no issues, update the
documentation to reflect the minimum required MSVC version as 2013
>
> This really doesn’t make sense if we are landing changes requiring MSVC
2013 between steps 3&5. Reverting as needed now that we have a stack of
changes that is piling up isn’t really viable anymore.
You are correct, if we need to revert, it would be challenging. My
understanding is that we do not need to revert any further, as
Chapuni's bots were the last ones that needed specific attention. The
lld and lldb bots may require further attention, but not certain
whether they require this change to be reverted? Those owners would
have to speak up with what they'd like to see happen.
> So I assume the new plan to just make anyone using MSVC update or they
can’t build anymore.
They couldn't build after step 3 anyway (almost any source changes
require CMake to rebuild the solutions, so any source fetches getting
newer code would also get the CMake files requiring a newer version of
MSVC before the solution can be generated). The repetition part of the
above steps is for build bots, not all users (though, obviously, if
there are major users who are stuck and didn't realize it until now,
we would have to figure out how to handle that).

~Aaron
>
> -Chris
>
>> On Feb 16, 2015, at 10:32 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>>
>> On Mon, Feb 16, 2015 at 1:22 PM, Chris Bieneman <beanz at
apple.com> wrote:
>>> + Chandler
>>>
>>> Ok… What’s going on here?
>>>
>>> I see Takumi re-landed the patches, but there have been a lot of
changes
>>> that came in yesterday that go against the plan for rolling this
out.
>>>
>>> The original plan (as proposed by Chandler) was to wait a week
after landing
>>> the CMake change before updating the documentation and allowing new
C++11
>>> features. This gives adequate time for people who may have missed
this
>>> thread to adjust.
>>
>> Once the CMake changes went live, anyone who was still on MSVC 2012
>> could no longer build, regardless. Waiting a week before landing
>> changes doesn't make that situation different for those users. I
was
>> under the impression that the week-long embargo was for the docs only,
>> and it was to give us time to stabilize bots as-needed while finding
>> out what works and does not work with MSVC 2013 in practice.
>>
>>> We now have uses of new C++11 features that aren’t supported by
VS2012
>>> littered around, which makes backing this change out far less
trivial.
>>>
>>> What is the plan now?
>>
>> I believe the plan is to continue ripping out MSVC 2012 (and earlier)
>> compatibility to determine the base feature set that's valid to
use.
>> For instance, my testing still shows that MSVC 2013 does not
>> synthesize move constructors properly, and so a lot of those hacks
>> must remain in place. However, it appears that = delete and explicit
>> operator support are sufficient to add to the set of working items.
>> From this, we can update the documentation.
>>
>> ~Aaron
>

> On Feb 16, 2015, at 10:47 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
> 
> On Mon, Feb 16, 2015 at 1:37 PM, Chris Bieneman <beanz at apple.com>
wrote:
>> The plan as stated was:
>> 
>> 1) Loop in cfe-dev and lldb-dev (Done!)
>> 2) Wait until this email fully circulates in digests and LLVM Weekly so
that everyone who has an objection can voice it
>> 3) If there are no objections, Commit a change to the CMake build which
errors on old MSVC versions
>> 4) Revert and fix buildbots
>> 5) Repeat 3 & 4 until no issues
> 
> It's my understanding that we're past step 5 currently, and waiting
to
> do step 6.
When I landed the change originally I saw no failures from any public bots. I
assume Takumi reverted it because there was a failure on a non-public bot. Since
the change re-landed on Sunday, I don’t think it is really safe to assume all
non-public bots had been migrated.

I’m not trying to stand in the way of progress here, but I do feel like we’ve
kinda thrown the plan to the wind here.
> 
>> 6) Once the change is live for a week with no issues, update the
documentation to reflect the minimum required MSVC version as 2013
>> 
>> This really doesn’t make sense if we are landing changes requiring MSVC
2013 between steps 3&5. Reverting as needed now that we have a stack of
changes that is piling up isn’t really viable anymore.
> 
> You are correct, if we need to revert, it would be challenging. My
> understanding is that we do not need to revert any further, as
> Chapuni's bots were the last ones that needed specific attention. The
> lld and lldb bots may require further attention, but not certain
> whether they require this change to be reverted? Those owners would
> have to speak up with what they'd like to see happen.
Hopefull there are no issues, but since this was re-landed on a Sunday when a
lot of people aren’t around and watching I’m nervous that we may have broken
things when people weren’t looking.
> 
>> So I assume the new plan to just make anyone using MSVC update or they
can’t build anymore.
> 
> They couldn't build after step 3 anyway (almost any source changes
> require CMake to rebuild the solutions, so any source fetches getting
> newer code would also get the CMake files requiring a newer version of
> MSVC before the solution can be generated). The repetition part of the
> above steps is for build bots, not all users (though, obviously, if
> there are major users who are stuck and didn't realize it until now,
> we would have to figure out how to handle that).
Right, but step 4 is to revert that change. We’ve now basically made it
prohibitively difficult to revert.

Look, I want to use variadic templates as much as the next guy, I’m just also
wanting to be considerate of our unfortunate colleagues using MSVC.

-Chris
> 
> ~Aaron
> 
>> 
>> -Chris
>> 
>>> On Feb 16, 2015, at 10:32 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>>> 
>>> On Mon, Feb 16, 2015 at 1:22 PM, Chris Bieneman <beanz at
apple.com> wrote:
>>>> + Chandler
>>>> 
>>>> Ok… What’s going on here?
>>>> 
>>>> I see Takumi re-landed the patches, but there have been a lot
of changes
>>>> that came in yesterday that go against the plan for rolling
this out.
>>>> 
>>>> The original plan (as proposed by Chandler) was to wait a week
after landing
>>>> the CMake change before updating the documentation and allowing
new C++11
>>>> features. This gives adequate time for people who may have
missed this
>>>> thread to adjust.
>>> 
>>> Once the CMake changes went live, anyone who was still on MSVC 2012
>>> could no longer build, regardless. Waiting a week before landing
>>> changes doesn't make that situation different for those users.
I was
>>> under the impression that the week-long embargo was for the docs
only,
>>> and it was to give us time to stabilize bots as-needed while
finding
>>> out what works and does not work with MSVC 2013 in practice.
>>> 
>>>> We now have uses of new C++11 features that aren’t supported by
VS2012
>>>> littered around, which makes backing this change out far less
trivial.
>>>> 
>>>> What is the plan now?
>>> 
>>> I believe the plan is to continue ripping out MSVC 2012 (and
earlier)
>>> compatibility to determine the base feature set that's valid to
use.
>>> For instance, my testing still shows that MSVC 2013 does not
>>> synthesize move constructors properly, and so a lot of those hacks
>>> must remain in place. However, it appears that = delete and
explicit
>>> operator support are sufficient to add to the set of working items.
>>> From this, we can update the documentation.
>>> 
>>> ~Aaron
>>

On Mon, Feb 16, 2015 at 2:42 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
>> On Feb 16, 2015, at 10:47 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>>
>> On Mon, Feb 16, 2015 at 1:37 PM, Chris Bieneman <beanz at
apple.com> wrote:
>>> The plan as stated was:
>>>
>>> 1) Loop in cfe-dev and lldb-dev (Done!)
>>> 2) Wait until this email fully circulates in digests and LLVM
Weekly so that everyone who has an objection can voice it
>>> 3) If there are no objections, Commit a change to the CMake build
which errors on old MSVC versions
>>> 4) Revert and fix buildbots
>>> 5) Repeat 3 & 4 until no issues
>>
>> It's my understanding that we're past step 5 currently, and
waiting to
>> do step 6.
>
> When I landed the change originally I saw no failures from any public bots.
I assume Takumi reverted it because there was a failure on a non-public bot.
Since the change re-landed on Sunday, I don’t think it is really safe to assume
all non-public bots had been migrated.
Takumi's bots are public bots: http://bb.pgr.jp/builders. They also
happily alert folks in IRC.
> I’m not trying to stand in the way of progress here, but I do feel like
we’ve kinda thrown the plan to the wind here.
I think we're following different plans; I think the progress d0k and
I have made was done following the plan. I may be wrong with my
understanding of the plan, however.
>
>>
>>> 6) Once the change is live for a week with no issues, update the
documentation to reflect the minimum required MSVC version as 2013
>>>
>>> This really doesn’t make sense if we are landing changes requiring
MSVC 2013 between steps 3&5. Reverting as needed now that we have a stack of
changes that is piling up isn’t really viable anymore.
>>
>> You are correct, if we need to revert, it would be challenging. My
>> understanding is that we do not need to revert any further, as
>> Chapuni's bots were the last ones that needed specific attention.
The
>> lld and lldb bots may require further attention, but not certain
>> whether they require this change to be reverted? Those owners would
>> have to speak up with what they'd like to see happen.
>
> Hopefull there are no issues, but since this was re-landed on a Sunday when
a lot of people aren’t around and watching I’m nervous that we may have broken
things when people weren’t looking.
I've not seen any bot-related issues arise in email or IRC yet, and I
suspect we would have tickled *something* by now if there were major
problems.
>
>>
>>> So I assume the new plan to just make anyone using MSVC update or
they can’t build anymore.
>>
>> They couldn't build after step 3 anyway (almost any source changes
>> require CMake to rebuild the solutions, so any source fetches getting
>> newer code would also get the CMake files requiring a newer version of
>> MSVC before the solution can be generated). The repetition part of the
>> above steps is for build bots, not all users (though, obviously, if
>> there are major users who are stuck and didn't realize it until
now,
>> we would have to figure out how to handle that).
>
> Right, but step 4 is to revert that change. We’ve now basically made it
prohibitively difficult to revert.
Agreed.
> Look, I want to use variadic templates as much as the next guy, I’m just
also wanting to be considerate of our unfortunate colleagues using MSVC.
As one of the people who was opposed to this change originally
specifically for that consideration, I appreciate it (though I would
not describe us as "unfortunate.")

~Aaron

> On Feb 16, 2015, at 11:53 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
> 
> On Mon, Feb 16, 2015 at 2:42 PM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>> 
>>> On Feb 16, 2015, at 10:47 AM, Aaron Ballman <aaron at
aaronballman.com> wrote:
>>> 
>>> On Mon, Feb 16, 2015 at 1:37 PM, Chris Bieneman <beanz at
apple.com> wrote:
>>>> The plan as stated was:
>>>> 
>>>> 1) Loop in cfe-dev and lldb-dev (Done!)
>>>> 2) Wait until this email fully circulates in digests and LLVM
Weekly so that everyone who has an objection can voice it
>>>> 3) If there are no objections, Commit a change to the CMake
build which errors on old MSVC versions
>>>> 4) Revert and fix buildbots
>>>> 5) Repeat 3 & 4 until no issues
>>> 
>>> It's my understanding that we're past step 5 currently, and
waiting to
>>> do step 6.
>> 
>> When I landed the change originally I saw no failures from any public
bots. I assume Takumi reverted it because there was a failure on a non-public
bot. Since the change re-landed on Sunday, I don’t think it is really safe to
assume all non-public bots had been migrated.
> 
> Takumi's bots are public bots: http://bb.pgr.jp/builders
<http://bb.pgr.jp/builders>. They also
> happily alert folks in IRC.
I’m aware of all this, and was on IRC when I landed the change on Friday, which
is why I was surprised when I didn’t see any failures, but my commit was still
reverted (hence my comment about assuming it was non-public).
> 
>> I’m not trying to stand in the way of progress here, but I do feel like
we’ve kinda thrown the plan to the wind here.
> 
> I think we're following different plans; I think the progress d0k and
> I have made was done following the plan. I may be wrong with my
> understanding of the plan, however.
I definitely think we had different interpretations of the plan. Maybe we should
be more explicit about timelines for transitions like this in the future.
> 
>> 
>>> 
>>>> 6) Once the change is live for a week with no issues, update
the documentation to reflect the minimum required MSVC version as 2013
>>>> 
>>>> This really doesn’t make sense if we are landing changes
requiring MSVC 2013 between steps 3&5. Reverting as needed now that we have
a stack of changes that is piling up isn’t really viable anymore.
>>> 
>>> You are correct, if we need to revert, it would be challenging. My
>>> understanding is that we do not need to revert any further, as
>>> Chapuni's bots were the last ones that needed specific
attention. The
>>> lld and lldb bots may require further attention, but not certain
>>> whether they require this change to be reverted? Those owners would
>>> have to speak up with what they'd like to see happen.
>> 
>> Hopefull there are no issues, but since this was re-landed on a Sunday
when a lot of people aren’t around and watching I’m nervous that we may have
broken things when people weren’t looking.
> 
> I've not seen any bot-related issues arise in email or IRC yet, and I
> suspect we would have tickled *something* by now if there were major
> problems.
I think you’re right, that at this point we are probably safe to assume all is
well in the world. I didn’t really feel that this was the case when I started
sending emails on this thread earlier this morning. I’m not sure what things are
like in your office, but Apple’s campus is a bit of a ghost town before 10am on
Monday mornings.
> 
>> 
>>> 
>>>> So I assume the new plan to just make anyone using MSVC update
or they can’t build anymore.
>>> 
>>> They couldn't build after step 3 anyway (almost any source
changes
>>> require CMake to rebuild the solutions, so any source fetches
getting
>>> newer code would also get the CMake files requiring a newer version
of
>>> MSVC before the solution can be generated). The repetition part of
the
>>> above steps is for build bots, not all users (though, obviously, if
>>> there are major users who are stuck and didn't realize it until
now,
>>> we would have to figure out how to handle that).
>> 
>> Right, but step 4 is to revert that change. We’ve now basically made it
prohibitively difficult to revert.
> 
> Agreed.
> 
>> Look, I want to use variadic templates as much as the next guy, I’m
just also wanting to be considerate of our unfortunate colleagues using MSVC.
> 
> As one of the people who was opposed to this change originally
> specifically for that consideration, I appreciate it (though I would
> not describe us as "unfortunate.”)
Don’t take it personally. I kinda view anyone not using Vim and Ninja as their
development environment as impoverished :-).

-Chris
> 
> ~Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/05d588ed/attachment.html>

On Mon, Feb 16, 2015 at 1:05 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
> On Feb 16, 2015, at 11:53 AM, Aaron Ballman <aaron at
aaronballman.com>
> wrote:
>
> On Mon, Feb 16, 2015 at 2:42 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
>
> On Feb 16, 2015, at 10:47 AM, Aaron Ballman <aaron at
aaronballman.com>
> wrote:
>
> On Mon, Feb 16, 2015 at 1:37 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
> The plan as stated was:
>
> 1) Loop in cfe-dev and lldb-dev (Done!)
> 2) Wait until this email fully circulates in digests and LLVM Weekly so
> that everyone who has an objection can voice it
> 3) If there are no objections, Commit a change to the CMake build which
> errors on old MSVC versions
> 4) Revert and fix buildbots
> 5) Repeat 3 & 4 until no issues
>
>
> It's my understanding that we're past step 5 currently, and waiting
to
> do step 6.
>
>
> When I landed the change originally I saw no failures from any public
> bots. I assume Takumi reverted it because there was a failure on a
> non-public bot. Since the change re-landed on Sunday, I don’t think it is
> really safe to assume all non-public bots had been migrated.
>
>
> Takumi's bots are public bots: http://bb.pgr.jp/builders. They also
> happily alert folks in IRC.
>
>
> I’m aware of all this, and was on IRC when I landed the change on Friday,
> which is why I was surprised when I didn’t see any failures, but my commit
> was still reverted (hence my comment about assuming it was non-public).
>
>
> I’m not trying to stand in the way of progress here, but I do feel like
> we’ve kinda thrown the plan to the wind here.
>
>
> I think we're following different plans; I think the progress d0k and
> I have made was done following the plan. I may be wrong with my
> understanding of the plan, however.
>
>
> I definitely think we had different interpretations of the plan. Maybe we
> should be more explicit about timelines for transitions like this in the
> future.
>
IIRC we actually discussed a pretty concrete process for MSVC min version
upgrades when we upped to 2012. I can't seem to find the thread though.

-- Sean

>
>
>
>
> 6) Once the change is live for a week with no issues, update the
> documentation to reflect the minimum required MSVC version as 2013
>
> This really doesn’t make sense if we are landing changes requiring MSVC
> 2013 between steps 3&5. Reverting as needed now that we have a stack of
> changes that is piling up isn’t really viable anymore.
>
>
> You are correct, if we need to revert, it would be challenging. My
> understanding is that we do not need to revert any further, as
> Chapuni's bots were the last ones that needed specific attention. The
> lld and lldb bots may require further attention, but not certain
> whether they require this change to be reverted? Those owners would
> have to speak up with what they'd like to see happen.
>
>
> Hopefull there are no issues, but since this was re-landed on a Sunday
> when a lot of people aren’t around and watching I’m nervous that we may
> have broken things when people weren’t looking.
>
>
> I've not seen any bot-related issues arise in email or IRC yet, and I
> suspect we would have tickled *something* by now if there were major
> problems.
>
>
> I think you’re right, that at this point we are probably safe to assume
> all is well in the world. I didn’t really feel that this was the case when
> I started sending emails on this thread earlier this morning. I’m not sure
> what things are like in your office, but Apple’s campus is a bit of a ghost
> town before 10am on Monday mornings.
>
>
>
>
> So I assume the new plan to just make anyone using MSVC update or they
> can’t build anymore.
>
>
> They couldn't build after step 3 anyway (almost any source changes
> require CMake to rebuild the solutions, so any source fetches getting
> newer code would also get the CMake files requiring a newer version of
> MSVC before the solution can be generated). The repetition part of the
> above steps is for build bots, not all users (though, obviously, if
> there are major users who are stuck and didn't realize it until now,
> we would have to figure out how to handle that).
>
>
> Right, but step 4 is to revert that change. We’ve now basically made it
> prohibitively difficult to revert.
>
>
> Agreed.
>
> Look, I want to use variadic templates as much as the next guy, I’m just
> also wanting to be considerate of our unfortunate colleagues using MSVC.
>
>
> As one of the people who was opposed to this change originally
> specifically for that consideration, I appreciate it (though I would
> not describe us as "unfortunate.”)
>
>
> Don’t take it personally. I kinda view anyone not using Vim and Ninja as
> their development environment as impoverished :-).
>
> -Chris
>
>
> ~Aaron
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150218/adc8eb70/attachment.html>