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 <amaior...@gmail.com> 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 <amaior...@gmail.com> wrote:
>>
>> Great, I'll get this working soon and attach a new patch :)
>>
>> On Mon, 28 Nov 2016 at 14:27 Hans Wennborg <h...@chromium.org> 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
>>> > -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 <h...@chromium.org> wrote:
>>> >>
>>> >> On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano
>>> >> <amaior...@gmail.com>
>>> >> 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 <h...@chromium.org>
>>> >> > 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 <ztur...@google.com>
>>> >> >> > 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
>>> >> >> >>> <amaior...@gmail.com>
>>> >> >> >>> 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
>>> >> >> >>>> <ztur...@google.com>
>>> >> >> >>>> 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.
>>> >> >> >>>>>>
>>> >> >> >>>>>> <Reference Include="Microsoft.VisualStudio.CoreUtility,
>>> >> >> >>>>>> Version=10.0.0.0, Culture=neutral,
>>> >> >> >>>>>> PublicKeyToken=b03f5f7f11d50a3a,
>>> >> >> >>>>>> processorArchitecture=MSIL" /> <Reference
>>> >> >> >>>>>> 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
>>> >> >> >>>>>> <amaior...@gmail.com>
>>> >> >> >>>>>> 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
>>> >> >> >>>>>>> <ztur...@google.com>
>>> >> >> >>>>>>> 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
>>> >> >> >>>>>>>> <h...@chromium.org>
>>> >> >> >>>>>>>> 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
>>> >> >> >>>>>>>>> <ztur...@google.com> 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
>>> >> >> >>>>>>>>> > <h...@chromium.org>
>>> >> >> >>>>>>>>> > 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
>>> >> >> >>>>>>>>> >> <ztur...@google.com>
>>> >> >> >>>>>>>>> >> 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
>>> >> >> >>>>>>>>> >> > <ztur...@google.com>
>>> >> >> >>>>>>>>> >> > 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
>>> >> >> >>>>>>>>> >> >>> <h...@chromium.org> wrote:
>>> >> >> >>>>>>>>> >> >>>>
>>> >> >> >>>>>>>>> >> >>>> Hi Antonio,
>>> >> >> >>>>>>>>> >> >>>>
>>> >> >> >>>>>>>>> >> >>>> On Wed, Aug 17, 2016 at 8:15 AM, Antonio Maiorano
>>> >> >> >>>>>>>>> >> >>>> via
>>> >> >> >>>>>>>>> >> >>>> cfe-commits
>>> >> >> >>>>>>>>> >> >>>> <cfe-commits@lists.llvm.org> 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
