Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Updated version of patch attached with the changes you suggested. Let me
know if there's anything else you'd like.

On Tue, 29 Nov 2016 at 15:38 Hans Wennborg  wrote:

> On Tue, Nov 29, 2016 at 12:01 PM, Antonio Maiorano 
> wrote:
> > On Tue, 29 Nov 2016 at 13:42 Hans Wennborg  wrote:
> >>
> >> Very nice! I've tried this out and confirmed that the built plugin
> >> also works with older Visual Studio versions.
> >>
> >> Some comments below:
> >>
> >> > --- /dev/null
> >> > +++ b/tools/clang-format-vs/.gitignore
> >> > @@ -0,0 +1,11 @@
> >> > +# Visual Studio files
> >> > +.vs/
> >> > +/packages/
> >> > +/ClangFormat/obj/
> >> > +/ClangFormat/bin/
> >>
> >> Should there really be a leading slash in these paths? Same below.
> >
> >
> > Without the leading slash, then it would match "ClangFormat/obj"
> anywhere in
> > the tree, rather than explicitly the one and only folder from the root.
> In
> > this case, it wouldn't matter much. If you prefer, I could just ignore
> > "obj/" and "bin/", etc, although I'd rather be explicit for Key.snk,
> > license.txt, etc.
>
> Interesting. I was just comparing with LLVM's root .gitignore, which
> doesn't have leading slashes for many dirs. Checking the gitignore
> doc, it sounds like you've got it right :-)
>
>
> >> > +# Generated and copied files
> >> > +/ClangFormat/Key.snk
> >> > +/ClangFormat/license.txt
> >> > +/ClangFormat/clang-format.exe
> >> > +/ClangFormat/source.extension.vsixmanifest
> >> > diff --git a/tools/clang-format-vs/CMakeLists.txt
> >> > b/tools/clang-format-vs/CMakeLists.txt
> >> > index fd0d6b0..90f89d8 100644
> >> > --- a/tools/clang-format-vs/CMakeLists.txt
> >> > +++ b/tools/clang-format-vs/CMakeLists.txt
> >> > @@ -18,8 +18,13 @@ if (BUILD_CLANG_FORMAT_VS_PLUGIN)
> >> >configure_file("source.extension.vsixmanifest.in"
> >> >
> >> >
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest")
> >> >
> >> > -  add_custom_target(clang_format_vsix ALL
> >> > -  devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build
> >> > Release
> >> > +  find_program(NUGET_EXE nuget PATHS ${NUGET_EXE_PATH})
> >> > +  if (NOT NUGET_EXE)
> >> > + message(FATAL_ERROR "Could not find nuget.exe. Download from
> >> > https://www.nuget.org/nuget.exe and add to PATH or pass path via
> >> > NUGET_EXE_PATH var")
> >>
> >> Can you break this string over multiple lines? I know there are pretty
> >> long lines in this file already, but it would be good to not make it
> >> worse.
> >
> >
> > Sure thing, I'll see what I can do :)
> >
> >>
> >>
> >> Maybe it could be clarified that NUGET_EXE_PATH is the path to a
> >> directory containing nuget.exe, not to the file itself (I ran into
> >> this). Maybe NUGET_EXE_DIR would be a better name?
> >
> >
> > That would be a better name, will make that change.
> >
> >>
> >>
> >> > +  endif()
> >> > +
> >> > +  add_custom_target(clang_format_vsix ALL
> >> > +  ${NUGET_EXE} restore "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln"
> &
> >> > devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
> >>
> >> Is '&' a CMake thing, or should that be '&&'? Also, any chance of
> >> breaking these long lines?
> >
> >
> > '&' is a cmd.exe thing, but I can use '&&' - in fact, the latter only
> runs
> > the 2nd command if the first succeeds, while using '&' always runs both.
> > I'll make the change, and will try to shorten this line as well.
> >
> >>
> >>
> >> >DEPENDS clang_format_exe_for_vsix
> >> >
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest"
> >> >COMMAND ${CMAKE_COMMAND} -E copy_if_different
> >> >
> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/bin/Release/ClangFormat.vsix"
> >> > diff --git a/tools/clang-format-vs/README.txt
> >> > b/tools/clang-format-vs/README.txt
> >> > index b23355d..44a071b 100644
> >> > --- a/tools/clang-format-vs/README.txt
> >> > +++ b/tools/clang-format-vs/README.txt
> >> > @@ -2,13 +2,23 @@ This directory contains a VSPackage project to
> >> > generate a Visual Studio extensio
> >> >  for clang-format.
> >> >
> >> >  Build prerequisites are:
> >> > -- Visual Studio 2013 Professional
> >> > -- Visual Studio 2013 SDK
> >> > -- Visual Studio 2010 Professional (?)
> >> > -- Visual Studio 2010 SDK (?)
> >> > +- Visual Studio 2015
> >> > +- Extensions SDK (you'll be prompted to install it if you open
> >> > ClangFormat.sln)
> >>
> >> A very nice simplification :-)
> >
> >
> > Thanks :)
> >
> >>
> >>
> >> >
> >> > -The extension is built using CMake by setting
> >> > BUILD_CLANG_FORMAT_VS_PLUGIN=ON
> >> > -when configuring a Clang build, and building the clang_format_vsix
> >> > target.
> >> > +The extension is built using CMake to generate the usual LLLVM.sln by
> >> > setting
> >>
> >> An L too much in LLLVM.sln?
> >
> >
> > You know, that extra L in 'L'egendary LLVM? ;) Will remove!
> >
> > Will update patch soon!
> >
> >>
> >>
> >> On Mon, Nov 28, 2016 at 8:00 PM, Antonio Maiorano 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

On Tue, 29 Nov 2016 at 13:42 Hans Wennborg  wrote:

> Very nice! I've tried this out and confirmed that the built plugin
> also works with older Visual Studio versions.
>
> Some comments below:
>
> > --- /dev/null
> > +++ b/tools/clang-format-vs/.gitignore
> > @@ -0,0 +1,11 @@
> > +# Visual Studio files
> > +.vs/
> > +/packages/
> > +/ClangFormat/obj/
> > +/ClangFormat/bin/
>
> Should there really be a leading slash in these paths? Same below.
>

Without the leading slash, then it would match "ClangFormat/obj" anywhere
in the tree, rather than explicitly the one and only folder from the root.
In this case, it wouldn't matter much. If you prefer, I could just ignore
"obj/" and "bin/", etc, although I'd rather be explicit for Key.snk,
license.txt, etc.


>
> > +
> > +# Generated and copied files
> > +/ClangFormat/Key.snk
> > +/ClangFormat/license.txt
> > +/ClangFormat/clang-format.exe
> > +/ClangFormat/source.extension.vsixmanifest
> > diff --git a/tools/clang-format-vs/CMakeLists.txt
> b/tools/clang-format-vs/CMakeLists.txt
> > index fd0d6b0..90f89d8 100644
> > --- a/tools/clang-format-vs/CMakeLists.txt
> > +++ b/tools/clang-format-vs/CMakeLists.txt
> > @@ -18,8 +18,13 @@ if (BUILD_CLANG_FORMAT_VS_PLUGIN)
> >configure_file("source.extension.vsixmanifest.in"
> >
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest")
> >
> > -  add_custom_target(clang_format_vsix ALL
> > -  devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build
> Release
> > +  find_program(NUGET_EXE nuget PATHS ${NUGET_EXE_PATH})
> > +  if (NOT NUGET_EXE)
> > + message(FATAL_ERROR "Could not find nuget.exe. Download from
> https://www.nuget.org/nuget.exe and add to PATH or pass path via
> NUGET_EXE_PATH var")
>
> Can you break this string over multiple lines? I know there are pretty
> long lines in this file already, but it would be good to not make it
> worse.
>

Sure thing, I'll see what I can do :)


>
> Maybe it could be clarified that NUGET_EXE_PATH is the path to a
> directory containing nuget.exe, not to the file itself (I ran into
> this). Maybe NUGET_EXE_DIR would be a better name?
>

That would be a better name, will make that change.


>
> > +  endif()
> > +
> > +  add_custom_target(clang_format_vsix ALL
> > +  ${NUGET_EXE} restore "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" &
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> Is '&' a CMake thing, or should that be '&&'? Also, any chance of
> breaking these long lines?
>

'&' is a cmd.exe thing, but I can use '&&' - in fact, the latter only runs
the 2nd command if the first succeeds, while using '&' always runs both.
I'll make the change, and will try to shorten this line as well.


>
> >DEPENDS clang_format_exe_for_vsix
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest"
> >COMMAND ${CMAKE_COMMAND} -E copy_if_different
> >
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/bin/Release/ClangFormat.vsix"
> > diff --git a/tools/clang-format-vs/README.txt
> b/tools/clang-format-vs/README.txt
> > index b23355d..44a071b 100644
> > --- a/tools/clang-format-vs/README.txt
> > +++ b/tools/clang-format-vs/README.txt
> > @@ -2,13 +2,23 @@ This directory contains a VSPackage project to
> generate a Visual Studio extensio
> >  for clang-format.
> >
> >  Build prerequisites are:
> > -- Visual Studio 2013 Professional
> > -- Visual Studio 2013 SDK
> > -- Visual Studio 2010 Professional (?)
> > -- Visual Studio 2010 SDK (?)
> > +- Visual Studio 2015
> > +- Extensions SDK (you'll be prompted to install it if you open
> ClangFormat.sln)
>
> A very nice simplification :-)
>

Thanks :)


>
> >
> > -The extension is built using CMake by setting
> BUILD_CLANG_FORMAT_VS_PLUGIN=ON
> > -when configuring a Clang build, and building the clang_format_vsix
> target.
> > +The extension is built using CMake to generate the usual LLLVM.sln by
> setting
>
> An L too much in LLLVM.sln?
>

You know, that extra L in 'L'egendary LLVM? ;) Will remove!

Will update patch soon!


>
> On Mon, Nov 28, 2016 at 8:00 PM, Antonio Maiorano 
> wrote:
> > I've attached a patch that works as discussed. When running CMake with
> > -DBUILD_CLANG_FORMAT_VS_PLUGIN=ON, it will look for nuget.exe in PATH, or
> > you can pass in DNUGET_EXE_PATH=C:\nuget, for e.g.
> >
> >
> > On Mon, 28 Nov 2016 at 14:31 Antonio Maiorano 
> wrote:
> >>
> >> Great, I'll get this working soon and attach a new patch :)
> >>
> >> On Mon, 28 Nov 2016 at 14:27 Hans Wennborg  wrote:
> >>>
> >>> On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano <
> amaior...@gmail.com>
> >>> wrote:
> >>> >> It's built with the script in utils/release/build_llvm_package.bat
> >>> > which I run manually on my machine once every few weeks.
> >>> >
> >>> > Okay, that's good news. So the simplest path to success would be to
> >>> > require
> >>> > the user to either pass the path to CMake via an arg like
> >>> > 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

I've attached a patch that works as discussed. When running CMake
with -DBUILD_CLANG_FORMAT_VS_PLUGIN=ON, it will look for nuget.exe in PATH,
or you can pass in DNUGET_EXE_PATH=C:\nuget, for e.g.


On Mon, 28 Nov 2016 at 14:31 Antonio Maiorano  wrote:

> Great, I'll get this working soon and attach a new patch :)
>
> On Mon, 28 Nov 2016 at 14:27 Hans Wennborg  wrote:
>
> On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano 
> wrote:
> >> It's built with the script in utils/release/build_llvm_package.bat
> > which I run manually on my machine once every few weeks.
> >
> > Okay, that's good news. So the simplest path to success would be to
> require
> > the user to either pass the path to CMake via an arg like
> -DNUGET_EXE_PATH,
> > or if it's not defined, to assume it's already in PATH. This is the most
> > future-proof solution as it will work with future versions of VS (2017 RC
> > just came out).
> >
> > I can still look into whether a vsix built with VS 2015 references will
> > continue to work in older versions of VS, but even if this works, I feel
> > like it's a temporary solution at best. There are other advantages to
> using
> > NuGet here: it would allow us to more easily pin/upgrade which
> assemblies we
> > want to use over time.
> >
> > If you're okay with it, I'll make the changes necessary to use
> > -DNUGET_EXE_PATH, if defined, otherwise assume it's on PATH. This should
> be
> > a simple change at this point.
>
> That sounds good to me. There are already a bunch of prerequisites for
> building the plugin, so adding this one doesn't seem unreasonable.
> Especially since it seems it will simplify things to the point that
> they might even work elsewhere than my own machine :-)
>
>
> > On Mon, 28 Nov 2016 at 13:59 Hans Wennborg  wrote:
> >>
> >> On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano  >
> >> wrote:
> >> > Okay, I'll see if upgrading to the 2015 assemblies would allow the
> VSIX
> >> > to
> >> > keep working in older versions of VS.
> >> >
> >> > Still waiting on an answer to this question:
> >> >
> >> >> In either case, though, I must ask: how is the offical vsix that's
> >> >> available on http://llvm.org/builds/ get built? Is it part of an
> >> >> automated
> >> >> Clang build, or is it built and uploaded manually? If it's automated,
> >> >> then
> >> >> having to download and point to nuget.exe won't work.
> >>
> >> It's built with the script in utils/release/build_llvm_package.bat
> >> which I run manually on my machine once every few weeks.
> >>
> >>
> >> > On Mon, 28 Nov 2016 at 13:04 Hans Wennborg  wrote:
> >> >>
> >> >> On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano <
> amaior...@gmail.com>
> >> >> wrote:
> >> >> > Ah, no, that's not what I meant. The required referenced assemblies
> >> >> > are
> >> >> > versions that are normally installed with VS 2010.
> >> >> >
> >> >> > The first time I worked on this, I had upgraded the referenced
> >> >> > assemblies to
> >> >> > the ones that ship with VS 2015, but then there was question of
> >> >> > whether
> >> >> > or
> >> >> > not the VSIX would continue to work with VS 2010/2012/2013. I'm not
> >> >> > sure
> >> >> > if
> >> >> > it would work, but I guess I can try to figure that out.
> >> >>
> >> >> Let me know if you figure this one out. It sounds like it would
> >> >> simplify things a lot.
> >> >>
> >> >> > In any case, what I discovered is that the "right" way to do things
> >> >> > to
> >> >> > make
> >> >> > sure your extension compiles in future versions of VS is to use
> NuGet
> >> >> > to
> >> >> > automatically pull in the required assemblies, or to check them in
> >> >> > and
> >> >> > reference them directly. The former would be better except for the
> >> >> > problem
> >> >> > of CLI builds as I described in my earlier email.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, 25 Nov 2016 at 21:47 Zachary Turner 
> >> >> > wrote:
> >> >> >>
> >> >> >> Sorry, i think I misunderstood the original option 1. I
> interpreted
> >> >> >> it
> >> >> >> as
> >> >> >> just committing changes to the vsix manifest to reference a
> specific
> >> >> >> version
> >> >> >> of the assembly which we assume to be present since it should be
> >> >> >> automatically installed with vs 2015. Is this not possible? Can't
> we
> >> >> >> just
> >> >> >> point the manifest to the version installed with vs?
> >> >> >> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano
> >> >> >> 
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Hi again,
> >> >> >>>
> >> >> >>> I've made the changes so that the required assemblies are
> >> >> >>> committed,
> >> >> >>> so
> >> >> >>> now we can build the clang-format-vsix with just VS 2015. Since
> the
> >> >> >>> patch
> >> >> >>> set is around 9 mb, I'm providing a link to it on my Dropbox (if
> >> >> >>> you'd
> >> >> >>> rather I attach it, let me 

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

Committed in r288393.

Cheers,
Hans

On Thu, Dec 1, 2016 at 9:22 AM, Hans Wennborg  wrote:
> Looks good to me!
>
> Do you have commit access, or would you like me to commit it for you?
>
> Thanks,
> Hans
>
> On Wed, Nov 30, 2016 at 8:10 PM, Antonio Maiorano  wrote:
>> Updated version of patch attached with the changes you suggested. Let me
>> know if there's anything else you'd like.
>>
>>
>> On Tue, 29 Nov 2016 at 15:38 Hans Wennborg  wrote:
>>>
>>> On Tue, Nov 29, 2016 at 12:01 PM, Antonio Maiorano 
>>> wrote:
>>> > On Tue, 29 Nov 2016 at 13:42 Hans Wennborg  wrote:
>>> >>
>>> >> Very nice! I've tried this out and confirmed that the built plugin
>>> >> also works with older Visual Studio versions.
>>> >>
>>> >> Some comments below:
>>> >>
>>> >> > --- /dev/null
>>> >> > +++ b/tools/clang-format-vs/.gitignore
>>> >> > @@ -0,0 +1,11 @@
>>> >> > +# Visual Studio files
>>> >> > +.vs/
>>> >> > +/packages/
>>> >> > +/ClangFormat/obj/
>>> >> > +/ClangFormat/bin/
>>> >>
>>> >> Should there really be a leading slash in these paths? Same below.
>>> >
>>> >
>>> > Without the leading slash, then it would match "ClangFormat/obj"
>>> > anywhere in
>>> > the tree, rather than explicitly the one and only folder from the root.
>>> > In
>>> > this case, it wouldn't matter much. If you prefer, I could just ignore
>>> > "obj/" and "bin/", etc, although I'd rather be explicit for Key.snk,
>>> > license.txt, etc.
>>>
>>> Interesting. I was just comparing with LLVM's root .gitignore, which
>>> doesn't have leading slashes for many dirs. Checking the gitignore
>>> doc, it sounds like you've got it right :-)
>>>
>>>
>>> >> > +# Generated and copied files
>>> >> > +/ClangFormat/Key.snk
>>> >> > +/ClangFormat/license.txt
>>> >> > +/ClangFormat/clang-format.exe
>>> >> > +/ClangFormat/source.extension.vsixmanifest
>>> >> > diff --git a/tools/clang-format-vs/CMakeLists.txt
>>> >> > b/tools/clang-format-vs/CMakeLists.txt
>>> >> > index fd0d6b0..90f89d8 100644
>>> >> > --- a/tools/clang-format-vs/CMakeLists.txt
>>> >> > +++ b/tools/clang-format-vs/CMakeLists.txt
>>> >> > @@ -18,8 +18,13 @@ if (BUILD_CLANG_FORMAT_VS_PLUGIN)
>>> >> >configure_file("source.extension.vsixmanifest.in"
>>> >> >
>>> >> >
>>> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest")
>>> >> >
>>> >> > -  add_custom_target(clang_format_vsix ALL
>>> >> > -  devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build
>>> >> > Release
>>> >> > +  find_program(NUGET_EXE nuget PATHS ${NUGET_EXE_PATH})
>>> >> > +  if (NOT NUGET_EXE)
>>> >> > + message(FATAL_ERROR "Could not find nuget.exe. Download from
>>> >> > https://www.nuget.org/nuget.exe and add to PATH or pass path via
>>> >> > NUGET_EXE_PATH var")
>>> >>
>>> >> Can you break this string over multiple lines? I know there are pretty
>>> >> long lines in this file already, but it would be good to not make it
>>> >> worse.
>>> >
>>> >
>>> > Sure thing, I'll see what I can do :)
>>> >
>>> >>
>>> >>
>>> >> Maybe it could be clarified that NUGET_EXE_PATH is the path to a
>>> >> directory containing nuget.exe, not to the file itself (I ran into
>>> >> this). Maybe NUGET_EXE_DIR would be a better name?
>>> >
>>> >
>>> > That would be a better name, will make that change.
>>> >
>>> >>
>>> >>
>>> >> > +  endif()
>>> >> > +
>>> >> > +  add_custom_target(clang_format_vsix ALL
>>> >> > +  ${NUGET_EXE} restore "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln"
>>> >> > &
>>> >> > devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>>> >>
>>> >> Is '&' a CMake thing, or should that be '&&'? Also, any chance of
>>> >> breaking these long lines?
>>> >
>>> >
>>> > '&' is a cmd.exe thing, but I can use '&&' - in fact, the latter only
>>> > runs
>>> > the 2nd command if the first succeeds, while using '&' always runs both.
>>> > I'll make the change, and will try to shorten this line as well.
>>> >
>>> >>
>>> >>
>>> >> >DEPENDS clang_format_exe_for_vsix
>>> >> >
>>> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest"
>>> >> >COMMAND ${CMAKE_COMMAND} -E copy_if_different
>>> >> >
>>> >> >
>>> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/bin/Release/ClangFormat.vsix"
>>> >> > diff --git a/tools/clang-format-vs/README.txt
>>> >> > b/tools/clang-format-vs/README.txt
>>> >> > index b23355d..44a071b 100644
>>> >> > --- a/tools/clang-format-vs/README.txt
>>> >> > +++ b/tools/clang-format-vs/README.txt
>>> >> > @@ -2,13 +2,23 @@ This directory contains a VSPackage project to
>>> >> > generate a Visual Studio extensio
>>> >> >  for clang-format.
>>> >> >
>>> >> >  Build prerequisites are:
>>> >> > -- Visual Studio 2013 Professional
>>> >> > -- Visual Studio 2013 SDK
>>> >> > -- Visual Studio 2010 Professional (?)
>>> >> > -- Visual Studio 2010 SDK (?)
>>> >> > +- Visual Studio 2015
>>> >> > +- Extensions SDK (you'll be prompted to install it if you open
>>> >> > 

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

Looks good to me!

Do you have commit access, or would you like me to commit it for you?

Thanks,
Hans

On Wed, Nov 30, 2016 at 8:10 PM, Antonio Maiorano  wrote:
> Updated version of patch attached with the changes you suggested. Let me
> know if there's anything else you'd like.
>
>
> On Tue, 29 Nov 2016 at 15:38 Hans Wennborg  wrote:
>>
>> On Tue, Nov 29, 2016 at 12:01 PM, Antonio Maiorano 
>> wrote:
>> > On Tue, 29 Nov 2016 at 13:42 Hans Wennborg  wrote:
>> >>
>> >> Very nice! I've tried this out and confirmed that the built plugin
>> >> also works with older Visual Studio versions.
>> >>
>> >> Some comments below:
>> >>
>> >> > --- /dev/null
>> >> > +++ b/tools/clang-format-vs/.gitignore
>> >> > @@ -0,0 +1,11 @@
>> >> > +# Visual Studio files
>> >> > +.vs/
>> >> > +/packages/
>> >> > +/ClangFormat/obj/
>> >> > +/ClangFormat/bin/
>> >>
>> >> Should there really be a leading slash in these paths? Same below.
>> >
>> >
>> > Without the leading slash, then it would match "ClangFormat/obj"
>> > anywhere in
>> > the tree, rather than explicitly the one and only folder from the root.
>> > In
>> > this case, it wouldn't matter much. If you prefer, I could just ignore
>> > "obj/" and "bin/", etc, although I'd rather be explicit for Key.snk,
>> > license.txt, etc.
>>
>> Interesting. I was just comparing with LLVM's root .gitignore, which
>> doesn't have leading slashes for many dirs. Checking the gitignore
>> doc, it sounds like you've got it right :-)
>>
>>
>> >> > +# Generated and copied files
>> >> > +/ClangFormat/Key.snk
>> >> > +/ClangFormat/license.txt
>> >> > +/ClangFormat/clang-format.exe
>> >> > +/ClangFormat/source.extension.vsixmanifest
>> >> > diff --git a/tools/clang-format-vs/CMakeLists.txt
>> >> > b/tools/clang-format-vs/CMakeLists.txt
>> >> > index fd0d6b0..90f89d8 100644
>> >> > --- a/tools/clang-format-vs/CMakeLists.txt
>> >> > +++ b/tools/clang-format-vs/CMakeLists.txt
>> >> > @@ -18,8 +18,13 @@ if (BUILD_CLANG_FORMAT_VS_PLUGIN)
>> >> >configure_file("source.extension.vsixmanifest.in"
>> >> >
>> >> >
>> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest")
>> >> >
>> >> > -  add_custom_target(clang_format_vsix ALL
>> >> > -  devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build
>> >> > Release
>> >> > +  find_program(NUGET_EXE nuget PATHS ${NUGET_EXE_PATH})
>> >> > +  if (NOT NUGET_EXE)
>> >> > + message(FATAL_ERROR "Could not find nuget.exe. Download from
>> >> > https://www.nuget.org/nuget.exe and add to PATH or pass path via
>> >> > NUGET_EXE_PATH var")
>> >>
>> >> Can you break this string over multiple lines? I know there are pretty
>> >> long lines in this file already, but it would be good to not make it
>> >> worse.
>> >
>> >
>> > Sure thing, I'll see what I can do :)
>> >
>> >>
>> >>
>> >> Maybe it could be clarified that NUGET_EXE_PATH is the path to a
>> >> directory containing nuget.exe, not to the file itself (I ran into
>> >> this). Maybe NUGET_EXE_DIR would be a better name?
>> >
>> >
>> > That would be a better name, will make that change.
>> >
>> >>
>> >>
>> >> > +  endif()
>> >> > +
>> >> > +  add_custom_target(clang_format_vsix ALL
>> >> > +  ${NUGET_EXE} restore "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln"
>> >> > &
>> >> > devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>> >>
>> >> Is '&' a CMake thing, or should that be '&&'? Also, any chance of
>> >> breaking these long lines?
>> >
>> >
>> > '&' is a cmd.exe thing, but I can use '&&' - in fact, the latter only
>> > runs
>> > the 2nd command if the first succeeds, while using '&' always runs both.
>> > I'll make the change, and will try to shorten this line as well.
>> >
>> >>
>> >>
>> >> >DEPENDS clang_format_exe_for_vsix
>> >> >
>> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest"
>> >> >COMMAND ${CMAKE_COMMAND} -E copy_if_different
>> >> >
>> >> >
>> >> > "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/bin/Release/ClangFormat.vsix"
>> >> > diff --git a/tools/clang-format-vs/README.txt
>> >> > b/tools/clang-format-vs/README.txt
>> >> > index b23355d..44a071b 100644
>> >> > --- a/tools/clang-format-vs/README.txt
>> >> > +++ b/tools/clang-format-vs/README.txt
>> >> > @@ -2,13 +2,23 @@ This directory contains a VSPackage project to
>> >> > generate a Visual Studio extensio
>> >> >  for clang-format.
>> >> >
>> >> >  Build prerequisites are:
>> >> > -- Visual Studio 2013 Professional
>> >> > -- Visual Studio 2013 SDK
>> >> > -- Visual Studio 2010 Professional (?)
>> >> > -- Visual Studio 2010 SDK (?)
>> >> > +- Visual Studio 2015
>> >> > +- Extensions SDK (you'll be prompted to install it if you open
>> >> > ClangFormat.sln)
>> >>
>> >> A very nice simplification :-)
>> >
>> >
>> > Thanks :)
>> >
>> >>
>> >>
>> >> >
>> >> > -The extension is built using CMake by setting
>> >> > BUILD_CLANG_FORMAT_VS_PLUGIN=ON
>> >> > -when configuring a Clang build, 

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

Very nice! I've tried this out and confirmed that the built plugin
also works with older Visual Studio versions.

Some comments below:

> --- /dev/null
> +++ b/tools/clang-format-vs/.gitignore
> @@ -0,0 +1,11 @@
> +# Visual Studio files
> +.vs/
> +/packages/
> +/ClangFormat/obj/
> +/ClangFormat/bin/

Should there really be a leading slash in these paths? Same below.

> +
> +# Generated and copied files
> +/ClangFormat/Key.snk
> +/ClangFormat/license.txt
> +/ClangFormat/clang-format.exe
> +/ClangFormat/source.extension.vsixmanifest
> diff --git a/tools/clang-format-vs/CMakeLists.txt 
> b/tools/clang-format-vs/CMakeLists.txt
> index fd0d6b0..90f89d8 100644
> --- a/tools/clang-format-vs/CMakeLists.txt
> +++ b/tools/clang-format-vs/CMakeLists.txt
> @@ -18,8 +18,13 @@ if (BUILD_CLANG_FORMAT_VS_PLUGIN)
>configure_file("source.extension.vsixmanifest.in"
>
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest")
>
> -  add_custom_target(clang_format_vsix ALL
> -  devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
> +  find_program(NUGET_EXE nuget PATHS ${NUGET_EXE_PATH})
> +  if (NOT NUGET_EXE)
> + message(FATAL_ERROR "Could not find nuget.exe. Download from 
> https://www.nuget.org/nuget.exe and add to PATH or pass path via 
> NUGET_EXE_PATH var")

Can you break this string over multiple lines? I know there are pretty
long lines in this file already, but it would be good to not make it
worse.

Maybe it could be clarified that NUGET_EXE_PATH is the path to a
directory containing nuget.exe, not to the file itself (I ran into
this). Maybe NUGET_EXE_DIR would be a better name?

> +  endif()
> +
> +  add_custom_target(clang_format_vsix ALL
> +  ${NUGET_EXE} restore "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" & 
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release

Is '&' a CMake thing, or should that be '&&'? Also, any chance of
breaking these long lines?

>DEPENDS clang_format_exe_for_vsix 
> "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/source.extension.vsixmanifest"
>COMMAND ${CMAKE_COMMAND} -E copy_if_different
>"${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat/bin/Release/ClangFormat.vsix"
> diff --git a/tools/clang-format-vs/README.txt 
> b/tools/clang-format-vs/README.txt
> index b23355d..44a071b 100644
> --- a/tools/clang-format-vs/README.txt
> +++ b/tools/clang-format-vs/README.txt
> @@ -2,13 +2,23 @@ This directory contains a VSPackage project to generate a 
> Visual Studio extensio
>  for clang-format.
>
>  Build prerequisites are:
> -- Visual Studio 2013 Professional
> -- Visual Studio 2013 SDK
> -- Visual Studio 2010 Professional (?)
> -- Visual Studio 2010 SDK (?)
> +- Visual Studio 2015
> +- Extensions SDK (you'll be prompted to install it if you open 
> ClangFormat.sln)

A very nice simplification :-)

>
> -The extension is built using CMake by setting BUILD_CLANG_FORMAT_VS_PLUGIN=ON
> -when configuring a Clang build, and building the clang_format_vsix target.
> +The extension is built using CMake to generate the usual LLLVM.sln by setting

An L too much in LLLVM.sln?


On Mon, Nov 28, 2016 at 8:00 PM, Antonio Maiorano  wrote:
> I've attached a patch that works as discussed. When running CMake with
> -DBUILD_CLANG_FORMAT_VS_PLUGIN=ON, it will look for nuget.exe in PATH, or
> you can pass in DNUGET_EXE_PATH=C:\nuget, for e.g.
>
>
> On Mon, 28 Nov 2016 at 14:31 Antonio Maiorano  wrote:
>>
>> Great, I'll get this working soon and attach a new patch :)
>>
>> On Mon, 28 Nov 2016 at 14:27 Hans Wennborg  wrote:
>>>
>>> On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano 
>>> wrote:
>>> >> It's built with the script in utils/release/build_llvm_package.bat
>>> > which I run manually on my machine once every few weeks.
>>> >
>>> > Okay, that's good news. So the simplest path to success would be to
>>> > require
>>> > the user to either pass the path to CMake via an arg like
>>> > -DNUGET_EXE_PATH,
>>> > or if it's not defined, to assume it's already in PATH. This is the
>>> > most
>>> > future-proof solution as it will work with future versions of VS (2017
>>> > RC
>>> > just came out).
>>> >
>>> > I can still look into whether a vsix built with VS 2015 references will
>>> > continue to work in older versions of VS, but even if this works, I
>>> > feel
>>> > like it's a temporary solution at best. There are other advantages to
>>> > using
>>> > NuGet here: it would allow us to more easily pin/upgrade which
>>> > assemblies we
>>> > want to use over time.
>>> >
>>> > If you're okay with it, I'll make the changes necessary to use
>>> > -DNUGET_EXE_PATH, if defined, otherwise assume it's on PATH. This
>>> > should be
>>> > a simple change at this point.
>>>
>>> That sounds good to me. There are already a bunch of prerequisites for
>>> building the plugin, so adding this one doesn't seem unreasonable.
>>> Especially since it seems it will simplify things to 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Great, I'll get this working soon and attach a new patch :)

On Mon, 28 Nov 2016 at 14:27 Hans Wennborg  wrote:

> On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano 
> wrote:
> >> It's built with the script in utils/release/build_llvm_package.bat
> > which I run manually on my machine once every few weeks.
> >
> > Okay, that's good news. So the simplest path to success would be to
> require
> > the user to either pass the path to CMake via an arg like
> -DNUGET_EXE_PATH,
> > or if it's not defined, to assume it's already in PATH. This is the most
> > future-proof solution as it will work with future versions of VS (2017 RC
> > just came out).
> >
> > I can still look into whether a vsix built with VS 2015 references will
> > continue to work in older versions of VS, but even if this works, I feel
> > like it's a temporary solution at best. There are other advantages to
> using
> > NuGet here: it would allow us to more easily pin/upgrade which
> assemblies we
> > want to use over time.
> >
> > If you're okay with it, I'll make the changes necessary to use
> > -DNUGET_EXE_PATH, if defined, otherwise assume it's on PATH. This should
> be
> > a simple change at this point.
>
> That sounds good to me. There are already a bunch of prerequisites for
> building the plugin, so adding this one doesn't seem unreasonable.
> Especially since it seems it will simplify things to the point that
> they might even work elsewhere than my own machine :-)
>
>
> > On Mon, 28 Nov 2016 at 13:59 Hans Wennborg  wrote:
> >>
> >> On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano  >
> >> wrote:
> >> > Okay, I'll see if upgrading to the 2015 assemblies would allow the
> VSIX
> >> > to
> >> > keep working in older versions of VS.
> >> >
> >> > Still waiting on an answer to this question:
> >> >
> >> >> In either case, though, I must ask: how is the offical vsix that's
> >> >> available on http://llvm.org/builds/ get built? Is it part of an
> >> >> automated
> >> >> Clang build, or is it built and uploaded manually? If it's automated,
> >> >> then
> >> >> having to download and point to nuget.exe won't work.
> >>
> >> It's built with the script in utils/release/build_llvm_package.bat
> >> which I run manually on my machine once every few weeks.
> >>
> >>
> >> > On Mon, 28 Nov 2016 at 13:04 Hans Wennborg  wrote:
> >> >>
> >> >> On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano <
> amaior...@gmail.com>
> >> >> wrote:
> >> >> > Ah, no, that's not what I meant. The required referenced assemblies
> >> >> > are
> >> >> > versions that are normally installed with VS 2010.
> >> >> >
> >> >> > The first time I worked on this, I had upgraded the referenced
> >> >> > assemblies to
> >> >> > the ones that ship with VS 2015, but then there was question of
> >> >> > whether
> >> >> > or
> >> >> > not the VSIX would continue to work with VS 2010/2012/2013. I'm not
> >> >> > sure
> >> >> > if
> >> >> > it would work, but I guess I can try to figure that out.
> >> >>
> >> >> Let me know if you figure this one out. It sounds like it would
> >> >> simplify things a lot.
> >> >>
> >> >> > In any case, what I discovered is that the "right" way to do things
> >> >> > to
> >> >> > make
> >> >> > sure your extension compiles in future versions of VS is to use
> NuGet
> >> >> > to
> >> >> > automatically pull in the required assemblies, or to check them in
> >> >> > and
> >> >> > reference them directly. The former would be better except for the
> >> >> > problem
> >> >> > of CLI builds as I described in my earlier email.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, 25 Nov 2016 at 21:47 Zachary Turner 
> >> >> > wrote:
> >> >> >>
> >> >> >> Sorry, i think I misunderstood the original option 1. I
> interpreted
> >> >> >> it
> >> >> >> as
> >> >> >> just committing changes to the vsix manifest to reference a
> specific
> >> >> >> version
> >> >> >> of the assembly which we assume to be present since it should be
> >> >> >> automatically installed with vs 2015. Is this not possible? Can't
> we
> >> >> >> just
> >> >> >> point the manifest to the version installed with vs?
> >> >> >> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano
> >> >> >> 
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Hi again,
> >> >> >>>
> >> >> >>> I've made the changes so that the required assemblies are
> >> >> >>> committed,
> >> >> >>> so
> >> >> >>> now we can build the clang-format-vsix with just VS 2015. Since
> the
> >> >> >>> patch
> >> >> >>> set is around 9 mb, I'm providing a link to it on my Dropbox (if
> >> >> >>> you'd
> >> >> >>> rather I attach it, let me know):
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
> >> >> >>>
> >> >> >>> Note that it's a git patch set, for which I followed the
> >> >> >>> 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Okay, I'll see if upgrading to the 2015 assemblies would allow the VSIX to
keep working in older versions of VS.

Still waiting on an answer to this question:

> In either case, though, I must ask: how is the offical vsix that's
available on http://llvm.org/builds/ get built? Is it part of an automated
Clang build, or is it built and uploaded manually? If it's automated, then
having to download and point to nuget.exe won't work.

Thanks!

On Mon, 28 Nov 2016 at 13:04 Hans Wennborg  wrote:

> On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano 
> wrote:
> > Ah, no, that's not what I meant. The required referenced assemblies are
> > versions that are normally installed with VS 2010.
> >
> > The first time I worked on this, I had upgraded the referenced
> assemblies to
> > the ones that ship with VS 2015, but then there was question of whether
> or
> > not the VSIX would continue to work with VS 2010/2012/2013. I'm not sure
> if
> > it would work, but I guess I can try to figure that out.
>
> Let me know if you figure this one out. It sounds like it would
> simplify things a lot.
>
> > In any case, what I discovered is that the "right" way to do things to
> make
> > sure your extension compiles in future versions of VS is to use NuGet to
> > automatically pull in the required assemblies, or to check them in and
> > reference them directly. The former would be better except for the
> problem
> > of CLI builds as I described in my earlier email.
> >
> >
> >
> > On Fri, 25 Nov 2016 at 21:47 Zachary Turner  wrote:
> >>
> >> Sorry, i think I misunderstood the original option 1. I interpreted it
> as
> >> just committing changes to the vsix manifest to reference a specific
> version
> >> of the assembly which we assume to be present since it should be
> >> automatically installed with vs 2015. Is this not possible? Can't we
> just
> >> point the manifest to the version installed with vs?
> >> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
> >> wrote:
> >>>
> >>> Hi again,
> >>>
> >>> I've made the changes so that the required assemblies are committed, so
> >>> now we can build the clang-format-vsix with just VS 2015. Since the
> patch
> >>> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
> >>> rather I attach it, let me know):
> >>>
> >>>
> >>>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
> >>>
> >>> Note that it's a git patch set, for which I followed the instructions
> >>> here.
> >>>
> >>> Thanks.
> >>>
> >>> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano 
> >>> wrote:
> 
>  Okay, that's fine, I'll go for that and if all looks good, will
> attach a
>  patch.
> 
>  Thanks.
> 
>  On Thu, 24 Nov 2016 at 15:09 Zachary Turner 
> wrote:
> >
> > I would use the first solution. We lock ourselves to specific
> versions
> > of vs, so i think it's fine to do the same with the assemblies and
> deal with
> > it only when we upgrade
> > On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano <
> amaior...@gmail.com>
> > wrote:
> >>
> >> Hi Hans,
> >>
> >> I saw that on September 15th, you checked in a change: clang-format
> VS
> >> plugin: upgrade the project files to VS2015.
> >>
> >> When I open the latest version of ClangFormat.sln on a machine that
> >> has only VS 2015, it doesn't build. The reason is that some of the
> >> referenced assemblies are from VS 2010.
> >>
> >>   >> Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0,
> Culture=neutral,
> >> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
> >>
> >> What happens is that when building, these specific assemblies are
> not
> >> found. I suspect you have VS 2010 installed on your machine, which
> is why
> >> you don't get these build errors.
> >>
> >> The recommended way to handle this is to make use of NuGet to have
> it
> >> automatically download the required assemblies. I have made the
> changes
> >> locally to get this working, and it works great when building
> >> ClangFormat.sln from within Visual Studio; however, building from
> the CLI
> >> doesn't work out of the box because you must explicitly run
> 'nuget.exe
> >> restore ClangFormat.sln' before running msbuild (or devenv.exe in
> our case).
> >> The problem is that nuget.exe isn't something that's easily
> found/accessible
> >> on Windows, even once installed as an extension in VS. This is a
> known
> >> problem and the current best solution requires downloading and
> making
> >> nuget.exe available in PATH.
> >>
> >> So now i'm faced with figuring out how best to solve this so that
> the
> >> custom build step in this CMakeLists.txt that runs devenv doesn't
> fail:
> >>
> >> devenv 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

> It's built with the script in utils/release/build_llvm_package.bat
which I run manually on my machine once every few weeks.

Okay, that's good news. So the simplest path to success would be to require
the user to either pass the path to CMake via an arg like -DNUGET_EXE_PATH,
or if it's not defined, to assume it's already in PATH. This is the most
future-proof solution as it will work with future versions of VS (2017 RC
just came out).

I can still look into whether a vsix built with VS 2015 references will
continue to work in older versions of VS, but even if this works, I feel
like it's a temporary solution at best. There are other advantages to using
NuGet here: it would allow us to more easily pin/upgrade which assemblies
we want to use over time.

If you're okay with it, I'll make the changes necessary to use
-DNUGET_EXE_PATH, if defined, otherwise assume it's on PATH. This should be
a simple change at this point.


On Mon, 28 Nov 2016 at 13:59 Hans Wennborg  wrote:

> On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano 
> wrote:
> > Okay, I'll see if upgrading to the 2015 assemblies would allow the VSIX
> to
> > keep working in older versions of VS.
> >
> > Still waiting on an answer to this question:
> >
> >> In either case, though, I must ask: how is the offical vsix that's
> >> available on http://llvm.org/builds/ get built? Is it part of an
> automated
> >> Clang build, or is it built and uploaded manually? If it's automated,
> then
> >> having to download and point to nuget.exe won't work.
>
> It's built with the script in utils/release/build_llvm_package.bat
> which I run manually on my machine once every few weeks.
>
>
> > On Mon, 28 Nov 2016 at 13:04 Hans Wennborg  wrote:
> >>
> >> On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano 
> >> wrote:
> >> > Ah, no, that's not what I meant. The required referenced assemblies
> are
> >> > versions that are normally installed with VS 2010.
> >> >
> >> > The first time I worked on this, I had upgraded the referenced
> >> > assemblies to
> >> > the ones that ship with VS 2015, but then there was question of
> whether
> >> > or
> >> > not the VSIX would continue to work with VS 2010/2012/2013. I'm not
> sure
> >> > if
> >> > it would work, but I guess I can try to figure that out.
> >>
> >> Let me know if you figure this one out. It sounds like it would
> >> simplify things a lot.
> >>
> >> > In any case, what I discovered is that the "right" way to do things to
> >> > make
> >> > sure your extension compiles in future versions of VS is to use NuGet
> to
> >> > automatically pull in the required assemblies, or to check them in and
> >> > reference them directly. The former would be better except for the
> >> > problem
> >> > of CLI builds as I described in my earlier email.
> >> >
> >> >
> >> >
> >> > On Fri, 25 Nov 2016 at 21:47 Zachary Turner 
> wrote:
> >> >>
> >> >> Sorry, i think I misunderstood the original option 1. I interpreted
> it
> >> >> as
> >> >> just committing changes to the vsix manifest to reference a specific
> >> >> version
> >> >> of the assembly which we assume to be present since it should be
> >> >> automatically installed with vs 2015. Is this not possible? Can't we
> >> >> just
> >> >> point the manifest to the version installed with vs?
> >> >> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano <
> amaior...@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Hi again,
> >> >>>
> >> >>> I've made the changes so that the required assemblies are committed,
> >> >>> so
> >> >>> now we can build the clang-format-vsix with just VS 2015. Since the
> >> >>> patch
> >> >>> set is around 9 mb, I'm providing a link to it on my Dropbox (if
> you'd
> >> >>> rather I attach it, let me know):
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
> >> >>>
> >> >>> Note that it's a git patch set, for which I followed the
> instructions
> >> >>> here.
> >> >>>
> >> >>> Thanks.
> >> >>>
> >> >>> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano 
> >> >>> wrote:
> >> 
> >>  Okay, that's fine, I'll go for that and if all looks good, will
> >>  attach a
> >>  patch.
> >> 
> >>  Thanks.
> >> 
> >>  On Thu, 24 Nov 2016 at 15:09 Zachary Turner 
> >>  wrote:
> >> >
> >> > I would use the first solution. We lock ourselves to specific
> >> > versions
> >> > of vs, so i think it's fine to do the same with the assemblies and
> >> > deal with
> >> > it only when we upgrade
> >> > On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano
> >> > 
> >> > wrote:
> >> >>
> >> >> Hi Hans,
> >> >>
> >> >> I saw that on September 15th, you checked in a change:
> clang-format
> >> >> VS
> >> >> plugin: upgrade the project files 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Unfortunately, vsvarsall doesn't bring nuget onto path. I shared a few
links earlier about this:
https://nuget.codeplex.com/workitem/3615
http://stackoverflow.com/questions/22300375/nuget-auto-package-restore-does-not-work-with-msbuild/23935892#23935892

Your idea about -DMSVC_NUGET_PATH for CMake is interesting, although at
that point, we may as well just ask the user to download
https://nuget.org/nuget.exe and add it to their PATH. In either case,
though, I must ask: how is the offical vsix that's available on
http://llvm.org/builds/ get built? Is it part of an automated Clang build,
or is it built and uploaded manually? If it's automated, then having to
download and point to nuget.exe won't work.

On Fri, 25 Nov 2016 at 22:15 Zachary Turner  wrote:

> Does running vcvarsall put nuget on the path?
>
> What if we require the user to specify the path to nuget in some CMake
> variable? -DMSVC_NUGET_PATH=foo?
> On Fri, Nov 25, 2016 at 6:58 PM Antonio Maiorano 
> wrote:
>
> Ah, no, that's not what I meant. The required referenced assemblies are
> versions that are normally installed with VS 2010.
>
> The first time I worked on this, I had upgraded the referenced assemblies
> to the ones that ship with VS 2015, but then there was question of whether
> or not the VSIX would continue to work with VS 2010/2012/2013. I'm not sure
> if it would work, but I guess I can try to figure that out.
>
> In any case, what I discovered is that the "right" way to do things to
> make sure your extension compiles in future versions of VS is to use NuGet
> to automatically pull in the required assemblies, or to check them in and
> reference them directly. The former would be better except for the problem
> of CLI builds as I described in my earlier email.
>
>
>
> On Fri, 25 Nov 2016 at 21:47 Zachary Turner  wrote:
>
> Sorry, i think I misunderstood the original option 1. I interpreted it as
> just committing changes to the vsix manifest to reference a specific
> version of the assembly which we assume to be present since it should be
> automatically installed with vs 2015. Is this not possible? Can't we just
> point the manifest to the version installed with vs?
> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
> wrote:
>
> Hi again,
>
> I've made the changes so that the required assemblies are committed, so
> now we can build the clang-format-vsix with just VS 2015. Since the patch
> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
> rather I attach it, let me know):
>
>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>
> Note that it's a git patch set, for which I followed the instructions here
> .
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano  wrote:
>
> Okay, that's fine, I'll go for that and if all looks good, will attach a
> patch.
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:
>
> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>
> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Ah, no, that's not what I meant. The required referenced assemblies are
versions that are normally installed with VS 2010.

The first time I worked on this, I had upgraded the referenced assemblies
to the ones that ship with VS 2015, but then there was question of whether
or not the VSIX would continue to work with VS 2010/2012/2013. I'm not sure
if it would work, but I guess I can try to figure that out.

In any case, what I discovered is that the "right" way to do things to make
sure your extension compiles in future versions of VS is to use NuGet to
automatically pull in the required assemblies, or to check them in and
reference them directly. The former would be better except for the problem
of CLI builds as I described in my earlier email.



On Fri, 25 Nov 2016 at 21:47 Zachary Turner  wrote:

> Sorry, i think I misunderstood the original option 1. I interpreted it as
> just committing changes to the vsix manifest to reference a specific
> version of the assembly which we assume to be present since it should be
> automatically installed with vs 2015. Is this not possible? Can't we just
> point the manifest to the version installed with vs?
> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
> wrote:
>
> Hi again,
>
> I've made the changes so that the required assemblies are committed, so
> now we can build the clang-format-vsix with just VS 2015. Since the patch
> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
> rather I attach it, let me know):
>
>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>
> Note that it's a git patch set, for which I followed the instructions here
> .
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano  wrote:
>
> Okay, that's fine, I'll go for that and if all looks good, will attach a
> patch.
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:
>
> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>
> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the
> custom build step in this CMakeLists.txt
> 
>  that
> runs devenv doesn't fail:
>
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> There are a few options:
>
> 1) Forget NuGet and just commit the referenced assemblies. This is the
> simplest solution, but is more annoying to manage if we want to upgrade the
> versions of these assemblies later.
>
> 2) Commit nuget.exe to the repo and just use it. This is simple enough,
> but I'm not sure how people feel about committing binaries, and it would be
> frozen at whatever version we commit.
>
> 3) Do some form of wget to grab the latest nuget.exe from "
> https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
> what's the simplest way to do this. Powershell could be used, but there are
> security annoyances to deal with.
>
> That's all I can come up with so far. Would love to hear from you guys if
> you have any ideas or opinions on this. If you want I can send you a 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Hi Hans,

I saw that on September 15th, you checked in a change: clang-format VS
plugin: upgrade the project files to VS2015.

When I open the latest version of ClangFormat.sln on a machine that has
only VS 2015, it doesn't build. The reason is that some of the referenced
assemblies are from VS 2010.

 

What happens is that when building, these specific assemblies are not
found. I suspect you have VS 2010 installed on your machine, which is why
you don't get these build errors.

The recommended way to handle this

is to make use of NuGet to have it automatically download the required
assemblies. I have made the changes locally to get this working, and it
works great when building ClangFormat.sln from within Visual Studio;
however, building from the CLI doesn't work out of the box because you must
explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
(or devenv.exe in our case). The problem is that nuget.exe isn't something
that's easily found/accessible on Windows, even once installed as an
extension in VS. This is a known problem
 and the current best solution
requires downloading and making nuget.exe available in PATH
.

So now i'm faced with figuring out how best to solve this so that the
custom build step in this CMakeLists.txt

that
runs devenv doesn't fail:

devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release

There are a few options:

1) Forget NuGet and just commit the referenced assemblies. This is the
simplest solution, but is more annoying to manage if we want to upgrade the
versions of these assemblies later.

2) Commit nuget.exe to the repo and just use it. This is simple enough, but
I'm not sure how people feel about committing binaries, and it would be
frozen at whatever version we commit.

3) Do some form of wget to grab the latest nuget.exe from "
https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
what's the simplest way to do this. Powershell could be used, but there are
security annoyances to deal with.

That's all I can come up with so far. Would love to hear from you guys if
you have any ideas or opinions on this. If you want I can send you a patch
of what I've got so far if that helps.

Thanks,

Antonio Maiorano



On Thu, 15 Sep 2016 at 19:35 Antonio Maiorano  wrote:

Sorry I haven't had a chance to get back to this. Things got busy at work.
I do plan to get back to this as I'm hoping to add some features to this
extension :)
On Thu, Sep 15, 2016 at 7:31 PM Zachary Turner  wrote:

Strange.  FWIW you can dump all the variables that are present in your
environment.  You need to go to Tools -> Options -> Projects and Solutions
-> Build and Run and choose either Normal, Detailed, or Diagnostic for the
MSBuild project build output verbosity.  Then in the output window you will
get a ton of spam, some of which is the set of all MSBuild variables you
can take advantage of.

On Thu, Sep 15, 2016 at 4:25 PM Hans Wennborg  wrote:

When I first opened the solution in VS it prompted me to install it and I
did.

On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner  wrote:
> You may need to install the Visual Studio SDK.  Did you do that when you
> initially installed VS 2015?
>
> On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:
>>
>> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
>> will need manual tweaking by whoever is trying to build the plugin.
>>
>> Anyway, I've updated the solution to build with VS2015 in r281648 and
>> confirmed that it can still be used with older VS versions too.
>>
>> Cheers,
>> Hans
>>
>> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
>> wrote:
>> > The key.snk is generated when you build, the problem is the csproj file
>> > hardcodes the directory to the sdk instead of using the appropriate
>> > project
>> > system variable like $(SDKToolsDir)
>> >
>> > On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner 
>> > wrote:
>> >>
>> >> Llvm doesn't support vs2012 anymore, as long as it supports vs2013
it's
>> >> fine
>> >> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano 
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> What I meant by upgrade was simply making it build in VS 2015.
>> >>> However,
>> >>> you bring up a valid point about making sure the extension will
>> >>> continue to
>> >>> work in VS 2012. I will look into that. Like those references that go
>> >>> from
>> >>> 10 to 14 that point out; I wonder if instead I should be able to
bring
>> >>> in
>> >>> those version 10 assemblies via NuGet. I'll take a closer look.
>> >>>
>> >>> Part of my change, however, seems to imply that the 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Okay, that's fine, I'll go for that and if all looks good, will attach a
patch.

Thanks.

On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:

> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>
> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the
> custom build step in this CMakeLists.txt
> 
>  that
> runs devenv doesn't fail:
>
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> There are a few options:
>
> 1) Forget NuGet and just commit the referenced assemblies. This is the
> simplest solution, but is more annoying to manage if we want to upgrade the
> versions of these assemblies later.
>
> 2) Commit nuget.exe to the repo and just use it. This is simple enough,
> but I'm not sure how people feel about committing binaries, and it would be
> frozen at whatever version we commit.
>
> 3) Do some form of wget to grab the latest nuget.exe from "
> https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
> what's the simplest way to do this. Powershell could be used, but there are
> security annoyances to deal with.
>
> That's all I can come up with so far. Would love to hear from you guys if
> you have any ideas or opinions on this. If you want I can send you a patch
> of what I've got so far if that helps.
>
> Thanks,
>
> Antonio Maiorano
>
>
>
> On Thu, 15 Sep 2016 at 19:35 Antonio Maiorano  wrote:
>
> Sorry I haven't had a chance to get back to this. Things got busy at work.
> I do plan to get back to this as I'm hoping to add some features to this
> extension :)
> On Thu, Sep 15, 2016 at 7:31 PM Zachary Turner  wrote:
>
> Strange.  FWIW you can dump all the variables that are present in your
> environment.  You need to go to Tools -> Options -> Projects and Solutions
> -> Build and Run and choose either Normal, Detailed, or Diagnostic for the
> MSBuild project build output verbosity.  Then in the output window you will
> get a ton of spam, some of which is the set of all MSBuild variables you
> can take advantage of.
>
> On Thu, Sep 15, 2016 at 4:25 PM Hans Wennborg  wrote:
>
> When I first opened the solution in VS it prompted me to install it and I
> did.
>
> On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner 
> wrote:
> > You may need to install the Visual Studio SDK.  Did you do that when you
> > initially installed VS 2015?
> >
> > On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:
> >>
> >> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
> >> will need manual tweaking by whoever is trying to build the plugin.
> >>
> >> Anyway, I've updated the solution to build with VS2015 in r281648 and
> >> confirmed that it can still be used with older VS versions too.
> >>
> >> Cheers,
> >> Hans
> >>
> >> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
> >> wrote:
> >> > The key.snk is generated when you build, the problem is the csproj
> file
> >> > hardcodes the directory to the sdk instead of using the appropriate
> >> > project
> >> > system variable like $(SDKToolsDir)
> >> >
> >> > On Thu, Aug 18, 2016 at 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Hi again,

I've made the changes so that the required assemblies are committed, so now
we can build the clang-format-vsix with just VS 2015. Since the patch set
is around 9 mb, I'm providing a link to it on my Dropbox (if you'd rather I
attach it, let me know):

https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch

Note that it's a git patch set, for which I followed the instructions here
.

Thanks.

On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano  wrote:

> Okay, that's fine, I'll go for that and if all looks good, will attach a
> patch.
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:
>
> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>
> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the
> custom build step in this CMakeLists.txt
> 
>  that
> runs devenv doesn't fail:
>
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> There are a few options:
>
> 1) Forget NuGet and just commit the referenced assemblies. This is the
> simplest solution, but is more annoying to manage if we want to upgrade the
> versions of these assemblies later.
>
> 2) Commit nuget.exe to the repo and just use it. This is simple enough,
> but I'm not sure how people feel about committing binaries, and it would be
> frozen at whatever version we commit.
>
> 3) Do some form of wget to grab the latest nuget.exe from "
> https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
> what's the simplest way to do this. Powershell could be used, but there are
> security annoyances to deal with.
>
> That's all I can come up with so far. Would love to hear from you guys if
> you have any ideas or opinions on this. If you want I can send you a patch
> of what I've got so far if that helps.
>
> Thanks,
>
> Antonio Maiorano
>
>
>
> On Thu, 15 Sep 2016 at 19:35 Antonio Maiorano  wrote:
>
> Sorry I haven't had a chance to get back to this. Things got busy at work.
> I do plan to get back to this as I'm hoping to add some features to this
> extension :)
> On Thu, Sep 15, 2016 at 7:31 PM Zachary Turner  wrote:
>
> Strange.  FWIW you can dump all the variables that are present in your
> environment.  You need to go to Tools -> Options -> Projects and Solutions
> -> Build and Run and choose either Normal, Detailed, or Diagnostic for the
> MSBuild project build output verbosity.  Then in the output window you will
> get a ton of spam, some of which is the set of all MSBuild variables you
> can take advantage of.
>
> On Thu, Sep 15, 2016 at 4:25 PM Hans Wennborg  wrote:
>
> When I first opened the solution in VS it prompted me to install it and I
> did.
>
> On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner 
> wrote:
> > You may need to install the Visual Studio SDK.  Did you do that when you
> > initially installed VS 2015?
> >
> > On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:
> >>
> >> Well, on my machine $(SDKToolsDir) 

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano  wrote:
>> It's built with the script in utils/release/build_llvm_package.bat
> which I run manually on my machine once every few weeks.
>
> Okay, that's good news. So the simplest path to success would be to require
> the user to either pass the path to CMake via an arg like -DNUGET_EXE_PATH,
> or if it's not defined, to assume it's already in PATH. This is the most
> future-proof solution as it will work with future versions of VS (2017 RC
> just came out).
>
> I can still look into whether a vsix built with VS 2015 references will
> continue to work in older versions of VS, but even if this works, I feel
> like it's a temporary solution at best. There are other advantages to using
> NuGet here: it would allow us to more easily pin/upgrade which assemblies we
> want to use over time.
>
> If you're okay with it, I'll make the changes necessary to use
> -DNUGET_EXE_PATH, if defined, otherwise assume it's on PATH. This should be
> a simple change at this point.

That sounds good to me. There are already a bunch of prerequisites for
building the plugin, so adding this one doesn't seem unreasonable.
Especially since it seems it will simplify things to the point that
they might even work elsewhere than my own machine :-)


> On Mon, 28 Nov 2016 at 13:59 Hans Wennborg  wrote:
>>
>> On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano 
>> wrote:
>> > Okay, I'll see if upgrading to the 2015 assemblies would allow the VSIX
>> > to
>> > keep working in older versions of VS.
>> >
>> > Still waiting on an answer to this question:
>> >
>> >> In either case, though, I must ask: how is the offical vsix that's
>> >> available on http://llvm.org/builds/ get built? Is it part of an
>> >> automated
>> >> Clang build, or is it built and uploaded manually? If it's automated,
>> >> then
>> >> having to download and point to nuget.exe won't work.
>>
>> It's built with the script in utils/release/build_llvm_package.bat
>> which I run manually on my machine once every few weeks.
>>
>>
>> > On Mon, 28 Nov 2016 at 13:04 Hans Wennborg  wrote:
>> >>
>> >> On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano 
>> >> wrote:
>> >> > Ah, no, that's not what I meant. The required referenced assemblies
>> >> > are
>> >> > versions that are normally installed with VS 2010.
>> >> >
>> >> > The first time I worked on this, I had upgraded the referenced
>> >> > assemblies to
>> >> > the ones that ship with VS 2015, but then there was question of
>> >> > whether
>> >> > or
>> >> > not the VSIX would continue to work with VS 2010/2012/2013. I'm not
>> >> > sure
>> >> > if
>> >> > it would work, but I guess I can try to figure that out.
>> >>
>> >> Let me know if you figure this one out. It sounds like it would
>> >> simplify things a lot.
>> >>
>> >> > In any case, what I discovered is that the "right" way to do things
>> >> > to
>> >> > make
>> >> > sure your extension compiles in future versions of VS is to use NuGet
>> >> > to
>> >> > automatically pull in the required assemblies, or to check them in
>> >> > and
>> >> > reference them directly. The former would be better except for the
>> >> > problem
>> >> > of CLI builds as I described in my earlier email.
>> >> >
>> >> >
>> >> >
>> >> > On Fri, 25 Nov 2016 at 21:47 Zachary Turner 
>> >> > wrote:
>> >> >>
>> >> >> Sorry, i think I misunderstood the original option 1. I interpreted
>> >> >> it
>> >> >> as
>> >> >> just committing changes to the vsix manifest to reference a specific
>> >> >> version
>> >> >> of the assembly which we assume to be present since it should be
>> >> >> automatically installed with vs 2015. Is this not possible? Can't we
>> >> >> just
>> >> >> point the manifest to the version installed with vs?
>> >> >> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi again,
>> >> >>>
>> >> >>> I've made the changes so that the required assemblies are
>> >> >>> committed,
>> >> >>> so
>> >> >>> now we can build the clang-format-vsix with just VS 2015. Since the
>> >> >>> patch
>> >> >>> set is around 9 mb, I'm providing a link to it on my Dropbox (if
>> >> >>> you'd
>> >> >>> rather I attach it, let me know):
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>> >> >>>
>> >> >>> Note that it's a git patch set, for which I followed the
>> >> >>> instructions
>> >> >>> here.
>> >> >>>
>> >> >>> Thanks.
>> >> >>>
>> >> >>> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano 
>> >> >>> wrote:
>> >> 
>> >>  Okay, that's fine, I'll go for that and if all looks good, will
>> >>  attach a
>> >>  patch.
>> >> 
>> >>  Thanks.
>> >> 
>> >>  On Thu, 24 Nov 2016 at 15:09 Zachary Turner 

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano  wrote:
> Okay, I'll see if upgrading to the 2015 assemblies would allow the VSIX to
> keep working in older versions of VS.
>
> Still waiting on an answer to this question:
>
>> In either case, though, I must ask: how is the offical vsix that's
>> available on http://llvm.org/builds/ get built? Is it part of an automated
>> Clang build, or is it built and uploaded manually? If it's automated, then
>> having to download and point to nuget.exe won't work.

It's built with the script in utils/release/build_llvm_package.bat
which I run manually on my machine once every few weeks.


> On Mon, 28 Nov 2016 at 13:04 Hans Wennborg  wrote:
>>
>> On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano 
>> wrote:
>> > Ah, no, that's not what I meant. The required referenced assemblies are
>> > versions that are normally installed with VS 2010.
>> >
>> > The first time I worked on this, I had upgraded the referenced
>> > assemblies to
>> > the ones that ship with VS 2015, but then there was question of whether
>> > or
>> > not the VSIX would continue to work with VS 2010/2012/2013. I'm not sure
>> > if
>> > it would work, but I guess I can try to figure that out.
>>
>> Let me know if you figure this one out. It sounds like it would
>> simplify things a lot.
>>
>> > In any case, what I discovered is that the "right" way to do things to
>> > make
>> > sure your extension compiles in future versions of VS is to use NuGet to
>> > automatically pull in the required assemblies, or to check them in and
>> > reference them directly. The former would be better except for the
>> > problem
>> > of CLI builds as I described in my earlier email.
>> >
>> >
>> >
>> > On Fri, 25 Nov 2016 at 21:47 Zachary Turner  wrote:
>> >>
>> >> Sorry, i think I misunderstood the original option 1. I interpreted it
>> >> as
>> >> just committing changes to the vsix manifest to reference a specific
>> >> version
>> >> of the assembly which we assume to be present since it should be
>> >> automatically installed with vs 2015. Is this not possible? Can't we
>> >> just
>> >> point the manifest to the version installed with vs?
>> >> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
>> >> wrote:
>> >>>
>> >>> Hi again,
>> >>>
>> >>> I've made the changes so that the required assemblies are committed,
>> >>> so
>> >>> now we can build the clang-format-vsix with just VS 2015. Since the
>> >>> patch
>> >>> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
>> >>> rather I attach it, let me know):
>> >>>
>> >>>
>> >>>
>> >>> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>> >>>
>> >>> Note that it's a git patch set, for which I followed the instructions
>> >>> here.
>> >>>
>> >>> Thanks.
>> >>>
>> >>> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano 
>> >>> wrote:
>> 
>>  Okay, that's fine, I'll go for that and if all looks good, will
>>  attach a
>>  patch.
>> 
>>  Thanks.
>> 
>>  On Thu, 24 Nov 2016 at 15:09 Zachary Turner 
>>  wrote:
>> >
>> > I would use the first solution. We lock ourselves to specific
>> > versions
>> > of vs, so i think it's fine to do the same with the assemblies and
>> > deal with
>> > it only when we upgrade
>> > On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano
>> > 
>> > wrote:
>> >>
>> >> Hi Hans,
>> >>
>> >> I saw that on September 15th, you checked in a change: clang-format
>> >> VS
>> >> plugin: upgrade the project files to VS2015.
>> >>
>> >> When I open the latest version of ClangFormat.sln on a machine that
>> >> has only VS 2015, it doesn't build. The reason is that some of the
>> >> referenced assemblies are from VS 2010.
>> >>
>> >>  > >> Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0,
>> >> Culture=neutral,
>> >> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>> >>
>> >> What happens is that when building, these specific assemblies are
>> >> not
>> >> found. I suspect you have VS 2010 installed on your machine, which
>> >> is why
>> >> you don't get these build errors.
>> >>
>> >> The recommended way to handle this is to make use of NuGet to have
>> >> it
>> >> automatically download the required assemblies. I have made the
>> >> changes
>> >> locally to get this working, and it works great when building
>> >> ClangFormat.sln from within Visual Studio; however, building from
>> >> the CLI
>> >> doesn't work out of the box because you must explicitly run
>> >> 'nuget.exe
>> >> restore ClangFormat.sln' before running msbuild (or devenv.exe in
>> >> our case).
>> >> The problem is that 

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano  wrote:
> Ah, no, that's not what I meant. The required referenced assemblies are
> versions that are normally installed with VS 2010.
>
> The first time I worked on this, I had upgraded the referenced assemblies to
> the ones that ship with VS 2015, but then there was question of whether or
> not the VSIX would continue to work with VS 2010/2012/2013. I'm not sure if
> it would work, but I guess I can try to figure that out.

Let me know if you figure this one out. It sounds like it would
simplify things a lot.

> In any case, what I discovered is that the "right" way to do things to make
> sure your extension compiles in future versions of VS is to use NuGet to
> automatically pull in the required assemblies, or to check them in and
> reference them directly. The former would be better except for the problem
> of CLI builds as I described in my earlier email.
>
>
>
> On Fri, 25 Nov 2016 at 21:47 Zachary Turner  wrote:
>>
>> Sorry, i think I misunderstood the original option 1. I interpreted it as
>> just committing changes to the vsix manifest to reference a specific version
>> of the assembly which we assume to be present since it should be
>> automatically installed with vs 2015. Is this not possible? Can't we just
>> point the manifest to the version installed with vs?
>> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
>> wrote:
>>>
>>> Hi again,
>>>
>>> I've made the changes so that the required assemblies are committed, so
>>> now we can build the clang-format-vsix with just VS 2015. Since the patch
>>> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
>>> rather I attach it, let me know):
>>>
>>>
>>> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>>>
>>> Note that it's a git patch set, for which I followed the instructions
>>> here.
>>>
>>> Thanks.
>>>
>>> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano 
>>> wrote:

 Okay, that's fine, I'll go for that and if all looks good, will attach a
 patch.

 Thanks.

 On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:
>
> I would use the first solution. We lock ourselves to specific versions
> of vs, so i think it's fine to do the same with the assemblies and deal 
> with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>>
>> Hi Hans,
>>
>> I saw that on September 15th, you checked in a change: clang-format VS
>> plugin: upgrade the project files to VS2015.
>>
>> When I open the latest version of ClangFormat.sln on a machine that
>> has only VS 2015, it doesn't build. The reason is that some of the
>> referenced assemblies are from VS 2010.
>>
>>  > Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, 
>> Culture=neutral,
>> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>>
>> What happens is that when building, these specific assemblies are not
>> found. I suspect you have VS 2010 installed on your machine, which is why
>> you don't get these build errors.
>>
>> The recommended way to handle this is to make use of NuGet to have it
>> automatically download the required assemblies. I have made the changes
>> locally to get this working, and it works great when building
>> ClangFormat.sln from within Visual Studio; however, building from the CLI
>> doesn't work out of the box because you must explicitly run 'nuget.exe
>> restore ClangFormat.sln' before running msbuild (or devenv.exe in our 
>> case).
>> The problem is that nuget.exe isn't something that's easily 
>> found/accessible
>> on Windows, even once installed as an extension in VS. This is a known
>> problem and the current best solution requires downloading and making
>> nuget.exe available in PATH.
>>
>> So now i'm faced with figuring out how best to solve this so that the
>> custom build step in this CMakeLists.txt that runs devenv doesn't fail:
>>
>> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>>
>> There are a few options:
>>
>> 1) Forget NuGet and just commit the referenced assemblies. This is the
>> simplest solution, but is more annoying to manage if we want to upgrade 
>> the
>> versions of these assemblies later.
>>
>> 2) Commit nuget.exe to the repo and just use it. This is simple
>> enough, but I'm not sure how people feel about committing binaries, and 
>> it
>> would be frozen at whatever version we commit.
>>
>> 3) Do some form of wget to grab the latest nuget.exe from
>> "https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
>> what's the simplest way to do 

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

Does running vcvarsall put nuget on the path?

What if we require the user to specify the path to nuget in some CMake
variable? -DMSVC_NUGET_PATH=foo?
On Fri, Nov 25, 2016 at 6:58 PM Antonio Maiorano 
wrote:

> Ah, no, that's not what I meant. The required referenced assemblies are
> versions that are normally installed with VS 2010.
>
> The first time I worked on this, I had upgraded the referenced assemblies
> to the ones that ship with VS 2015, but then there was question of whether
> or not the VSIX would continue to work with VS 2010/2012/2013. I'm not sure
> if it would work, but I guess I can try to figure that out.
>
> In any case, what I discovered is that the "right" way to do things to
> make sure your extension compiles in future versions of VS is to use NuGet
> to automatically pull in the required assemblies, or to check them in and
> reference them directly. The former would be better except for the problem
> of CLI builds as I described in my earlier email.
>
>
>
> On Fri, 25 Nov 2016 at 21:47 Zachary Turner  wrote:
>
> Sorry, i think I misunderstood the original option 1. I interpreted it as
> just committing changes to the vsix manifest to reference a specific
> version of the assembly which we assume to be present since it should be
> automatically installed with vs 2015. Is this not possible? Can't we just
> point the manifest to the version installed with vs?
> On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
> wrote:
>
> Hi again,
>
> I've made the changes so that the required assemblies are committed, so
> now we can build the clang-format-vsix with just VS 2015. Since the patch
> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
> rather I attach it, let me know):
>
>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>
> Note that it's a git patch set, for which I followed the instructions here
> .
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano  wrote:
>
> Okay, that's fine, I'll go for that and if all looks good, will attach a
> patch.
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:
>
> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>
> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the
> custom build step in this CMakeLists.txt
> 
>  that
> runs devenv doesn't fail:
>
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> There are a few options:
>
> 1) Forget NuGet and just commit the referenced assemblies. This is the
> simplest solution, but is more annoying to manage if we want to upgrade the
> versions of these assemblies later.
>
> 2) Commit nuget.exe to the repo and just use it. This is simple enough,
> but I'm not sure how people feel about committing binaries, and it would be
> frozen at whatever version we commit.
>
> 3) Do some form of wget to grab the latest nuget.exe from "
> https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
> 

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

Sorry, i think I misunderstood the original option 1. I interpreted it as
just committing changes to the vsix manifest to reference a specific
version of the assembly which we assume to be present since it should be
automatically installed with vs 2015. Is this not possible? Can't we just
point the manifest to the version installed with vs?
On Fri, Nov 25, 2016 at 6:20 PM Antonio Maiorano 
wrote:

> Hi again,
>
> I've made the changes so that the required assemblies are committed, so
> now we can build the clang-format-vsix with just VS 2015. Since the patch
> set is around 9 mb, I'm providing a link to it on my Dropbox (if you'd
> rather I attach it, let me know):
>
>
> https://dl.dropboxusercontent.com/u/10504225/llvm-patches/0001-Fix-VS2015-build-of-clang-format-vsix-by-committing-.patch
>
> Note that it's a git patch set, for which I followed the instructions here
> .
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:45 Antonio Maiorano  wrote:
>
> Okay, that's fine, I'll go for that and if all looks good, will attach a
> patch.
>
> Thanks.
>
> On Thu, 24 Nov 2016 at 15:09 Zachary Turner  wrote:
>
> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it only when we upgrade
> On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
> wrote:
>
> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the
> custom build step in this CMakeLists.txt
> 
>  that
> runs devenv doesn't fail:
>
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> There are a few options:
>
> 1) Forget NuGet and just commit the referenced assemblies. This is the
> simplest solution, but is more annoying to manage if we want to upgrade the
> versions of these assemblies later.
>
> 2) Commit nuget.exe to the repo and just use it. This is simple enough,
> but I'm not sure how people feel about committing binaries, and it would be
> frozen at whatever version we commit.
>
> 3) Do some form of wget to grab the latest nuget.exe from "
> https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
> what's the simplest way to do this. Powershell could be used, but there are
> security annoyances to deal with.
>
> That's all I can come up with so far. Would love to hear from you guys if
> you have any ideas or opinions on this. If you want I can send you a patch
> of what I've got so far if that helps.
>
> Thanks,
>
> Antonio Maiorano
>
>
>
> On Thu, 15 Sep 2016 at 19:35 Antonio Maiorano  wrote:
>
> Sorry I haven't had a chance to get back to this. Things got busy at work.
> I do plan to get back to this as I'm hoping to add some features to this
> extension :)
> On Thu, Sep 15, 2016 at 7:31 PM Zachary Turner  wrote:
>
> Strange.  FWIW you can dump all the variables that are present in your
> environment.  You need to go to Tools -> Options -> Projects and Solutions
> -> Build and Run and choose either Normal, Detailed, or Diagnostic for the
> MSBuild project build output verbosity.  Then in the output window you will
> get a ton of spam, some of which is the set of all MSBuild variables you
> can take advantage of.
>
> On Thu, Sep 15, 2016 at 

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

I would use the first solution. We lock ourselves to specific versions of
vs, so i think it's fine to do the same with the assemblies and deal with
it only when we upgrade
On Thu, Nov 24, 2016 at 11:29 AM Antonio Maiorano 
wrote:

> Hi Hans,
>
> I saw that on September 15th, you checked in a change: clang-format VS
> plugin: upgrade the project files to VS2015.
>
> When I open the latest version of ClangFormat.sln on a machine that has
> only VS 2015, it doesn't build. The reason is that some of the referenced
> assemblies are from VS 2010.
>
>   Include="Microsoft.VisualStudio.Editor, Version=10.0.0.0, Culture=neutral,
> PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />
>
> What happens is that when building, these specific assemblies are not
> found. I suspect you have VS 2010 installed on your machine, which is why
> you don't get these build errors.
>
> The recommended way to handle this
> 
> is to make use of NuGet to have it automatically download the required
> assemblies. I have made the changes locally to get this working, and it
> works great when building ClangFormat.sln from within Visual Studio;
> however, building from the CLI doesn't work out of the box because you must
> explicitly run 'nuget.exe restore ClangFormat.sln' before running msbuild
> (or devenv.exe in our case). The problem is that nuget.exe isn't something
> that's easily found/accessible on Windows, even once installed as an
> extension in VS. This is a known problem
>  and the current best solution
> requires downloading and making nuget.exe available in PATH
> .
>
> So now i'm faced with figuring out how best to solve this so that the
> custom build step in this CMakeLists.txt
> 
>  that
> runs devenv doesn't fail:
>
> devenv "${CMAKE_CURRENT_SOURCE_DIR}/ClangFormat.sln" /Build Release
>
> There are a few options:
>
> 1) Forget NuGet and just commit the referenced assemblies. This is the
> simplest solution, but is more annoying to manage if we want to upgrade the
> versions of these assemblies later.
>
> 2) Commit nuget.exe to the repo and just use it. This is simple enough,
> but I'm not sure how people feel about committing binaries, and it would be
> frozen at whatever version we commit.
>
> 3) Do some form of wget to grab the latest nuget.exe from "
> https://nuget.org/nuget.exe; in CMake and invoke it. I'm not yet sure
> what's the simplest way to do this. Powershell could be used, but there are
> security annoyances to deal with.
>
> That's all I can come up with so far. Would love to hear from you guys if
> you have any ideas or opinions on this. If you want I can send you a patch
> of what I've got so far if that helps.
>
> Thanks,
>
> Antonio Maiorano
>
>
>
> On Thu, 15 Sep 2016 at 19:35 Antonio Maiorano  wrote:
>
> Sorry I haven't had a chance to get back to this. Things got busy at work.
> I do plan to get back to this as I'm hoping to add some features to this
> extension :)
> On Thu, Sep 15, 2016 at 7:31 PM Zachary Turner  wrote:
>
> Strange.  FWIW you can dump all the variables that are present in your
> environment.  You need to go to Tools -> Options -> Projects and Solutions
> -> Build and Run and choose either Normal, Detailed, or Diagnostic for the
> MSBuild project build output verbosity.  Then in the output window you will
> get a ton of spam, some of which is the set of all MSBuild variables you
> can take advantage of.
>
> On Thu, Sep 15, 2016 at 4:25 PM Hans Wennborg  wrote:
>
> When I first opened the solution in VS it prompted me to install it and I
> did.
>
> On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner 
> wrote:
> > You may need to install the Visual Studio SDK.  Did you do that when you
> > initially installed VS 2015?
> >
> > On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:
> >>
> >> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
> >> will need manual tweaking by whoever is trying to build the plugin.
> >>
> >> Anyway, I've updated the solution to build with VS2015 in r281648 and
> >> confirmed that it can still be used with older VS versions too.
> >>
> >> Cheers,
> >> Hans
> >>
> >> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
> >> wrote:
> >> > The key.snk is generated when you build, the problem is the csproj
> file
> >> > hardcodes the directory to the sdk instead of using the appropriate
> >> > project
> >> > system variable like $(SDKToolsDir)
> >> >
> >> > On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner 
> >> > wrote:
> >> >>
> >> >> Llvm doesn't support vs2012 anymore, as long as it supports vs2013
> it's
> >> >> fine
> >> >> On 

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Sorry I haven't had a chance to get back to this. Things got busy at work.
I do plan to get back to this as I'm hoping to add some features to this
extension :)
On Thu, Sep 15, 2016 at 7:31 PM Zachary Turner  wrote:

> Strange.  FWIW you can dump all the variables that are present in your
> environment.  You need to go to Tools -> Options -> Projects and Solutions
> -> Build and Run and choose either Normal, Detailed, or Diagnostic for the
> MSBuild project build output verbosity.  Then in the output window you will
> get a ton of spam, some of which is the set of all MSBuild variables you
> can take advantage of.
>
> On Thu, Sep 15, 2016 at 4:25 PM Hans Wennborg  wrote:
>
>> When I first opened the solution in VS it prompted me to install it and I
>> did.
>>
>> On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner 
>> wrote:
>> > You may need to install the Visual Studio SDK.  Did you do that when you
>> > initially installed VS 2015?
>> >
>> > On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg 
>> wrote:
>> >>
>> >> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
>> >> will need manual tweaking by whoever is trying to build the plugin.
>> >>
>> >> Anyway, I've updated the solution to build with VS2015 in r281648 and
>> >> confirmed that it can still be used with older VS versions too.
>> >>
>> >> Cheers,
>> >> Hans
>> >>
>> >> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
>> >> wrote:
>> >> > The key.snk is generated when you build, the problem is the csproj
>> file
>> >> > hardcodes the directory to the sdk instead of using the appropriate
>> >> > project
>> >> > system variable like $(SDKToolsDir)
>> >> >
>> >> > On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner 
>> >> > wrote:
>> >> >>
>> >> >> Llvm doesn't support vs2012 anymore, as long as it supports vs2013
>> it's
>> >> >> fine
>> >> >> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano <
>> amaior...@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> What I meant by upgrade was simply making it build in VS 2015.
>> >> >>> However,
>> >> >>> you bring up a valid point about making sure the extension will
>> >> >>> continue to
>> >> >>> work in VS 2012. I will look into that. Like those references that
>> go
>> >> >>> from
>> >> >>> 10 to 14 that point out; I wonder if instead I should be able to
>> bring
>> >> >>> in
>> >> >>> those version 10 assemblies via NuGet. I'll take a closer look.
>> >> >>>
>> >> >>> Part of my change, however, seems to imply that the extension
>> (vsix)
>> >> >>> project would not build correctly even in VS 2012. For instance,
>> the
>> >> >>> missing
>> >> >>> Key.snk file. I don't have VS 2012 installed at the moment, so I
>> >> >>> cannot
>> >> >>> validate.
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> Antonio
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg 
>> wrote:
>> >> 
>> >>  Hi Antonio,
>> >> 
>> >>  On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
>> >>   wrote:
>> >>  > This patch for clang-format-vs includes the following:
>> >>  >
>> >>  > - Upgrade to VS 2015, including .NET framework upgrade from 4.0
>> to
>> >>  > 4.5, and
>> >>  > upgrading Microsoft.VisualStudio references to v14 versions
>> >>  > - Fix build by removing dependency on "Key.snk" file which was
>> >>  > never
>> >>  > checked
>> >>  > in (and not really required anyway)
>> >>  > - Add ".vs" directory to svn ignore (new folder that VS 2015
>> >>  > creates
>> >>  > for
>> >>  > user settings)
>> >> 
>> >>  "What does "Upgrade to VS 2015 mean? Adding support for running
>> the
>> >>  plugin in VS2015, or does it mean requiring VS2015 for building?
>> >> 
>> >>  +zturner: I thought the plugin already worked in VS 2015?
>> >> 
>> >>  I mostly just build the plugin without knowing exactly how this
>> stuff
>> >>  works, but looking at the patch I'm worried that you're increasing
>> >>  the
>> >>  required version for building it? I see a bunch of values going
>> from
>> >>  10 (VS 2012) to 14 (VS 2015).
>> >> 
>> >>  Thanks,
>> >>  Hans
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

Strange.  FWIW you can dump all the variables that are present in your
environment.  You need to go to Tools -> Options -> Projects and Solutions
-> Build and Run and choose either Normal, Detailed, or Diagnostic for the
MSBuild project build output verbosity.  Then in the output window you will
get a ton of spam, some of which is the set of all MSBuild variables you
can take advantage of.

On Thu, Sep 15, 2016 at 4:25 PM Hans Wennborg  wrote:

> When I first opened the solution in VS it prompted me to install it and I
> did.
>
> On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner 
> wrote:
> > You may need to install the Visual Studio SDK.  Did you do that when you
> > initially installed VS 2015?
> >
> > On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:
> >>
> >> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
> >> will need manual tweaking by whoever is trying to build the plugin.
> >>
> >> Anyway, I've updated the solution to build with VS2015 in r281648 and
> >> confirmed that it can still be used with older VS versions too.
> >>
> >> Cheers,
> >> Hans
> >>
> >> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
> >> wrote:
> >> > The key.snk is generated when you build, the problem is the csproj
> file
> >> > hardcodes the directory to the sdk instead of using the appropriate
> >> > project
> >> > system variable like $(SDKToolsDir)
> >> >
> >> > On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner 
> >> > wrote:
> >> >>
> >> >> Llvm doesn't support vs2012 anymore, as long as it supports vs2013
> it's
> >> >> fine
> >> >> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano <
> amaior...@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> What I meant by upgrade was simply making it build in VS 2015.
> >> >>> However,
> >> >>> you bring up a valid point about making sure the extension will
> >> >>> continue to
> >> >>> work in VS 2012. I will look into that. Like those references that
> go
> >> >>> from
> >> >>> 10 to 14 that point out; I wonder if instead I should be able to
> bring
> >> >>> in
> >> >>> those version 10 assemblies via NuGet. I'll take a closer look.
> >> >>>
> >> >>> Part of my change, however, seems to imply that the extension (vsix)
> >> >>> project would not build correctly even in VS 2012. For instance, the
> >> >>> missing
> >> >>> Key.snk file. I don't have VS 2012 installed at the moment, so I
> >> >>> cannot
> >> >>> validate.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Antonio
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg 
> wrote:
> >> 
> >>  Hi Antonio,
> >> 
> >>  On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
> >>   wrote:
> >>  > This patch for clang-format-vs includes the following:
> >>  >
> >>  > - Upgrade to VS 2015, including .NET framework upgrade from 4.0
> to
> >>  > 4.5, and
> >>  > upgrading Microsoft.VisualStudio references to v14 versions
> >>  > - Fix build by removing dependency on "Key.snk" file which was
> >>  > never
> >>  > checked
> >>  > in (and not really required anyway)
> >>  > - Add ".vs" directory to svn ignore (new folder that VS 2015
> >>  > creates
> >>  > for
> >>  > user settings)
> >> 
> >>  "What does "Upgrade to VS 2015 mean? Adding support for running the
> >>  plugin in VS2015, or does it mean requiring VS2015 for building?
> >> 
> >>  +zturner: I thought the plugin already worked in VS 2015?
> >> 
> >>  I mostly just build the plugin without knowing exactly how this
> stuff
> >>  works, but looking at the patch I'm worried that you're increasing
> >>  the
> >>  required version for building it? I see a bunch of values going
> from
> >>  10 (VS 2012) to 14 (VS 2015).
> >> 
> >>  Thanks,
> >>  Hans
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

When I first opened the solution in VS it prompted me to install it and I did.

On Thu, Sep 15, 2016 at 4:17 PM, Zachary Turner  wrote:
> You may need to install the Visual Studio SDK.  Did you do that when you
> initially installed VS 2015?
>
> On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:
>>
>> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
>> will need manual tweaking by whoever is trying to build the plugin.
>>
>> Anyway, I've updated the solution to build with VS2015 in r281648 and
>> confirmed that it can still be used with older VS versions too.
>>
>> Cheers,
>> Hans
>>
>> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
>> wrote:
>> > The key.snk is generated when you build, the problem is the csproj file
>> > hardcodes the directory to the sdk instead of using the appropriate
>> > project
>> > system variable like $(SDKToolsDir)
>> >
>> > On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner 
>> > wrote:
>> >>
>> >> Llvm doesn't support vs2012 anymore, as long as it supports vs2013 it's
>> >> fine
>> >> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano 
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> What I meant by upgrade was simply making it build in VS 2015.
>> >>> However,
>> >>> you bring up a valid point about making sure the extension will
>> >>> continue to
>> >>> work in VS 2012. I will look into that. Like those references that go
>> >>> from
>> >>> 10 to 14 that point out; I wonder if instead I should be able to bring
>> >>> in
>> >>> those version 10 assemblies via NuGet. I'll take a closer look.
>> >>>
>> >>> Part of my change, however, seems to imply that the extension (vsix)
>> >>> project would not build correctly even in VS 2012. For instance, the
>> >>> missing
>> >>> Key.snk file. I don't have VS 2012 installed at the moment, so I
>> >>> cannot
>> >>> validate.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Antonio
>> >>>
>> >>>
>> >>>
>> >>> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg  wrote:
>> 
>>  Hi Antonio,
>> 
>>  On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
>>   wrote:
>>  > This patch for clang-format-vs includes the following:
>>  >
>>  > - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to
>>  > 4.5, and
>>  > upgrading Microsoft.VisualStudio references to v14 versions
>>  > - Fix build by removing dependency on "Key.snk" file which was
>>  > never
>>  > checked
>>  > in (and not really required anyway)
>>  > - Add ".vs" directory to svn ignore (new folder that VS 2015
>>  > creates
>>  > for
>>  > user settings)
>> 
>>  "What does "Upgrade to VS 2015 mean? Adding support for running the
>>  plugin in VS2015, or does it mean requiring VS2015 for building?
>> 
>>  +zturner: I thought the plugin already worked in VS 2015?
>> 
>>  I mostly just build the plugin without knowing exactly how this stuff
>>  works, but looking at the patch I'm worried that you're increasing
>>  the
>>  required version for building it? I see a bunch of values going from
>>  10 (VS 2012) to 14 (VS 2015).
>> 
>>  Thanks,
>>  Hans
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

You may need to install the Visual Studio SDK.  Did you do that when you
initially installed VS 2015?

On Thu, Sep 15, 2016 at 4:15 PM Hans Wennborg  wrote:

> Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
> will need manual tweaking by whoever is trying to build the plugin.
>
> Anyway, I've updated the solution to build with VS2015 in r281648 and
> confirmed that it can still be used with older VS versions too.
>
> Cheers,
> Hans
>
> On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner 
> wrote:
> > The key.snk is generated when you build, the problem is the csproj file
> > hardcodes the directory to the sdk instead of using the appropriate
> project
> > system variable like $(SDKToolsDir)
> >
> > On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner 
> wrote:
> >>
> >> Llvm doesn't support vs2012 anymore, as long as it supports vs2013 it's
> >> fine
> >> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano 
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> What I meant by upgrade was simply making it build in VS 2015. However,
> >>> you bring up a valid point about making sure the extension will
> continue to
> >>> work in VS 2012. I will look into that. Like those references that go
> from
> >>> 10 to 14 that point out; I wonder if instead I should be able to bring
> in
> >>> those version 10 assemblies via NuGet. I'll take a closer look.
> >>>
> >>> Part of my change, however, seems to imply that the extension (vsix)
> >>> project would not build correctly even in VS 2012. For instance, the
> missing
> >>> Key.snk file. I don't have VS 2012 installed at the moment, so I cannot
> >>> validate.
> >>>
> >>> Thanks,
> >>>
> >>> Antonio
> >>>
> >>>
> >>>
> >>> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg  wrote:
> 
>  Hi Antonio,
> 
>  On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
>   wrote:
>  > This patch for clang-format-vs includes the following:
>  >
>  > - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to
>  > 4.5, and
>  > upgrading Microsoft.VisualStudio references to v14 versions
>  > - Fix build by removing dependency on "Key.snk" file which was never
>  > checked
>  > in (and not really required anyway)
>  > - Add ".vs" directory to svn ignore (new folder that VS 2015 creates
>  > for
>  > user settings)
> 
>  "What does "Upgrade to VS 2015 mean? Adding support for running the
>  plugin in VS2015, or does it mean requiring VS2015 for building?
> 
>  +zturner: I thought the plugin already worked in VS 2015?
> 
>  I mostly just build the plugin without knowing exactly how this stuff
>  works, but looking at the patch I'm worried that you're increasing the
>  required version for building it? I see a bunch of values going from
>  10 (VS 2012) to 14 (VS 2015).
> 
>  Thanks,
>  Hans
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

Well, on my machine $(SDKToolsDir) doesn't work :-( I suspect the file
will need manual tweaking by whoever is trying to build the plugin.

Anyway, I've updated the solution to build with VS2015 in r281648 and
confirmed that it can still be used with older VS versions too.

Cheers,
Hans

On Thu, Aug 18, 2016 at 7:11 PM, Zachary Turner  wrote:
> The key.snk is generated when you build, the problem is the csproj file
> hardcodes the directory to the sdk instead of using the appropriate project
> system variable like $(SDKToolsDir)
>
> On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner  wrote:
>>
>> Llvm doesn't support vs2012 anymore, as long as it supports vs2013 it's
>> fine
>> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano 
>> wrote:
>>>
>>> Hi,
>>>
>>> What I meant by upgrade was simply making it build in VS 2015. However,
>>> you bring up a valid point about making sure the extension will continue to
>>> work in VS 2012. I will look into that. Like those references that go from
>>> 10 to 14 that point out; I wonder if instead I should be able to bring in
>>> those version 10 assemblies via NuGet. I'll take a closer look.
>>>
>>> Part of my change, however, seems to imply that the extension (vsix)
>>> project would not build correctly even in VS 2012. For instance, the missing
>>> Key.snk file. I don't have VS 2012 installed at the moment, so I cannot
>>> validate.
>>>
>>> Thanks,
>>>
>>> Antonio
>>>
>>>
>>>
>>> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg  wrote:

 Hi Antonio,

 On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
  wrote:
 > This patch for clang-format-vs includes the following:
 >
 > - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to
 > 4.5, and
 > upgrading Microsoft.VisualStudio references to v14 versions
 > - Fix build by removing dependency on "Key.snk" file which was never
 > checked
 > in (and not really required anyway)
 > - Add ".vs" directory to svn ignore (new folder that VS 2015 creates
 > for
 > user settings)

 "What does "Upgrade to VS 2015 mean? Adding support for running the
 plugin in VS2015, or does it mean requiring VS2015 for building?

 +zturner: I thought the plugin already worked in VS 2015?

 I mostly just build the plugin without knowing exactly how this stuff
 works, but looking at the patch I'm worried that you're increasing the
 required version for building it? I see a bunch of values going from
 10 (VS 2012) to 14 (VS 2015).

 Thanks,
 Hans
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Hi,

What I meant by upgrade was simply making it build in VS 2015. However, you
bring up a valid point about making sure the extension will continue to
work in VS 2012. I will look into that. Like those references that go from
10 to 14 that point out; I wonder if instead I should be able to bring in
those version 10 assemblies via NuGet. I'll take a closer look.

Part of my change, however, seems to imply that the extension (vsix)
project would not build correctly even in VS 2012. For instance, the
missing Key.snk file. I don't have VS 2012 installed at the moment, so I
cannot validate.

Thanks,

Antonio



On Thu, 18 Aug 2016 at 19:38 Hans Wennborg  wrote:

> Hi Antonio,
>
> On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
>  wrote:
> > This patch for clang-format-vs includes the following:
> >
> > - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to 4.5,
> and
> > upgrading Microsoft.VisualStudio references to v14 versions
> > - Fix build by removing dependency on "Key.snk" file which was never
> checked
> > in (and not really required anyway)
> > - Add ".vs" directory to svn ignore (new folder that VS 2015 creates for
> > user settings)
>
> "What does "Upgrade to VS 2015 mean? Adding support for running the
> plugin in VS2015, or does it mean requiring VS2015 for building?
>
> +zturner: I thought the plugin already worked in VS 2015?
>
> I mostly just build the plugin without knowing exactly how this stuff
> works, but looking at the patch I'm worried that you're increasing the
> required version for building it? I see a bunch of values going from
> 10 (VS 2012) to 14 (VS 2015).
>
> Thanks,
> Hans
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

The key.snk is generated when you build, the problem is the csproj file
hardcodes the directory to the sdk instead of using the appropriate project
system variable like $(SDKToolsDir)
On Thu, Aug 18, 2016 at 7:09 PM Zachary Turner  wrote:

> Llvm doesn't support vs2012 anymore, as long as it supports vs2013 it's
> fine
> On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano 
> wrote:
>
>> Hi,
>>
>> What I meant by upgrade was simply making it build in VS 2015. However,
>> you bring up a valid point about making sure the extension will continue to
>> work in VS 2012. I will look into that. Like those references that go from
>> 10 to 14 that point out; I wonder if instead I should be able to bring in
>> those version 10 assemblies via NuGet. I'll take a closer look.
>>
>> Part of my change, however, seems to imply that the extension (vsix)
>> project would not build correctly even in VS 2012. For instance, the
>> missing Key.snk file. I don't have VS 2012 installed at the moment, so I
>> cannot validate.
>>
>> Thanks,
>>
>> Antonio
>>
>>
>>
>> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg  wrote:
>>
>>> Hi Antonio,
>>>
>>> On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
>>>  wrote:
>>> > This patch for clang-format-vs includes the following:
>>> >
>>> > - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to
>>> 4.5, and
>>> > upgrading Microsoft.VisualStudio references to v14 versions
>>> > - Fix build by removing dependency on "Key.snk" file which was never
>>> checked
>>> > in (and not really required anyway)
>>> > - Add ".vs" directory to svn ignore (new folder that VS 2015 creates
>>> for
>>> > user settings)
>>>
>>> "What does "Upgrade to VS 2015 mean? Adding support for running the
>>> plugin in VS2015, or does it mean requiring VS2015 for building?
>>>
>>> +zturner: I thought the plugin already worked in VS 2015?
>>>
>>> I mostly just build the plugin without knowing exactly how this stuff
>>> works, but looking at the patch I'm worried that you're increasing the
>>> required version for building it? I see a bunch of values going from
>>> 10 (VS 2012) to 14 (VS 2015).
>>>
>>> Thanks,
>>> Hans
>>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Zachary Turner via cfe-commits]

Llvm doesn't support vs2012 anymore, as long as it supports vs2013 it's
fine
On Thu, Aug 18, 2016 at 7:07 PM Antonio Maiorano 
wrote:

> Hi,
>
> What I meant by upgrade was simply making it build in VS 2015. However,
> you bring up a valid point about making sure the extension will continue to
> work in VS 2012. I will look into that. Like those references that go from
> 10 to 14 that point out; I wonder if instead I should be able to bring in
> those version 10 assemblies via NuGet. I'll take a closer look.
>
> Part of my change, however, seems to imply that the extension (vsix)
> project would not build correctly even in VS 2012. For instance, the
> missing Key.snk file. I don't have VS 2012 installed at the moment, so I
> cannot validate.
>
> Thanks,
>
> Antonio
>
>
>
> On Thu, 18 Aug 2016 at 19:38 Hans Wennborg  wrote:
>
>> Hi Antonio,
>>
>> On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
>>  wrote:
>> > This patch for clang-format-vs includes the following:
>> >
>> > - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to 4.5,
>> and
>> > upgrading Microsoft.VisualStudio references to v14 versions
>> > - Fix build by removing dependency on "Key.snk" file which was never
>> checked
>> > in (and not really required anyway)
>> > - Add ".vs" directory to svn ignore (new folder that VS 2015 creates for
>> > user settings)
>>
>> "What does "Upgrade to VS 2015 mean? Adding support for running the
>> plugin in VS2015, or does it mean requiring VS2015 for building?
>>
>> +zturner: I thought the plugin already worked in VS 2015?
>>
>> I mostly just build the plugin without knowing exactly how this stuff
>> works, but looking at the patch I'm worried that you're increasing the
>> required version for building it? I see a bunch of values going from
>> 10 (VS 2012) to 14 (VS 2015).
>>
>> Thanks,
>> Hans
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Upgrade and fix clang-format-vs

[Hans Wennborg via cfe-commits]

Hi Antonio,

On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano via cfe-commits
 wrote:
> This patch for clang-format-vs includes the following:
>
> - Upgrade to VS 2015, including .NET framework upgrade from 4.0 to 4.5, and
> upgrading Microsoft.VisualStudio references to v14 versions
> - Fix build by removing dependency on "Key.snk" file which was never checked
> in (and not really required anyway)
> - Add ".vs" directory to svn ignore (new folder that VS 2015 creates for
> user settings)

"What does "Upgrade to VS 2015 mean? Adding support for running the
plugin in VS2015, or does it mean requiring VS2015 for building?

+zturner: I thought the plugin already worked in VS 2015?

I mostly just build the plugin without knowing exactly how this stuff
works, but looking at the patch I'm worried that you're increasing the
required version for building it? I see a bunch of values going from
10 (VS 2012) to 14 (VS 2015).

Thanks,
Hans
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Upgrade and fix clang-format-vs

[Antonio Maiorano via cfe-commits]

Hello,

This patch for clang-format-vs includes the following:

- Upgrade to VS 2015, including .NET framework upgrade from 4.0 to 4.5, and
upgrading Microsoft.VisualStudio references to v14 versions
- Fix build by removing dependency on "Key.snk" file which was never
checked in (and not really required anyway)
- Add ".vs" directory to svn ignore (new folder that VS 2015 creates for
user settings)

Antonio Maiorano


clang-format-vs-to-vs2015.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits