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:
> >>
> >> Ver
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
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
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 attac
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 N
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
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
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 f
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 autom
> 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 defin
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
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 cont
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 201
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
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/
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 p
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
>>
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
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
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
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
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
> environ
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
ge
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:
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
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, Au
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
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 suppor
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
> wo
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
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 req
31 matches
Mail list logo
