[cfe-dev] Incomplete binary distribution windows

[Hans Wennborg via cfe-dev]

On Thu, Aug 9, 2018 at 2:20 PM, Zachary Turner <zturner at google.com> wrote:
> Agreed, the old way was basically a hack because it was the only way to get
> it working. But a vsix is the “proper” solution for having an extension.
> It’s unfortunate that installing a toolchain with a vsix only became
> possible in 2017, but that’s out of our control.
>
> Shipping the old install batch files as-is but not updated for 2017 I guess
> is an option

I don't think we should be shipping them since we won't be maintaining them.

The old files are available for anyone to put up on GitHub or
something if they want to maintain them.

> On Thu, Aug 9, 2018 at 8:12 AM Hans Wennborg <hans at chromium.org> wrote:
>>
>> On Thu, Aug 9, 2018 at 6:52 AM, degski <degski at gmail.com> wrote:
>> > On Wed, 8 Aug 2018 at 20:49, Zachary Turner <zturner at google.com> wrote:
>> >>
>> >> Unfortunately the new integration will *not* work in vs2015. I meant to
>> >> fix this in the vsix (that was the other change I forgot to push). The
>> >> reason is that the ability of an extension to properly install itself
>> >> as a
>> >> toolchain only became possible in 2017, so there’s no way that I’m
>> >> aware to
>> >> even do this in 2015 with a vsix.
>> >
>> >
>> > There seem to be (not me) an awful lot of people that cannot/don't want
>> > to
>> > move from VS15 (or even VS13/12), so the above is unfortunate as we seem
>> > to
>> > have moved from one extreme to the other. If one assumes a standard
>> > installation of VS17, changing the (old) installer batch file to also
>> > install for VS17 is not too hard. There is also this utility
>> > https://github.com/Microsoft/vswhere, which can help, in case of
>> > non-standard installations. I'm not sure whether dealing with those more
>> > complex situations is desirable, though. The people with the more
>> > complex
>> > installations are probably also capable enough to get things working
>> > correctly and satisfactory "old school".
>>
>> I don't think we want to go back to the old integration though, even
>> if it can be made to work with VS 2017.
>>
>> It's cool that developers made that work on their own, and unfortunate
>> that we broke it by not installing a ms-build-bin\cl.exe file. I
>> suppose we could put that file back, but it also seems like a pretty
>> narrow use case. Perhaps users who have managed to make the old
>> extension still work for them could do the copy themselves.
>>
>> I'm not sure what the best thing to do is here. Shipping the new
>> integration breaks users who were relying on the old one, but that
>> also seems inevitable, and maybe worth it for having a new extension
>> that works well with VS 2017.
>>
>>  - Hans