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