[PATCH] D114639: Raise the minimum Visual Studio version to VS2019

[James Henderson via Phabricator via cfe-commits]

jhenderson added a comment.

Re. the bots: I'd hope we'd have at least some bots using VS2019 rather than all rushing to VS2022. There's nothing worse than claiming to support a minimum version of something and then not actually supporting it...! Also internally, we are switching to a default of VS2019, not direct to VS2022, so having upstream coverage there would be useful to avoid downstream breakages that are actually upstream problems - we're working on adding our own Windows build bot, but I don't think it's there yet.



================
Comment at: clang/docs/UsersManual.rst:3546
 
-    cmake -G"Visual Studio 15 2017" -T LLVM ..
+    cmake -G"Visual Studio 17 2022" -T LLVM ..
 
----------------
stella.stamenova wrote:
> compnerd wrote:
> > Meinersbur wrote:
> > > jhenderson wrote:
> > > > RKSimon wrote:
> > > > > aaron.ballman wrote:
> > > > > > jhenderson wrote:
> > > > > > > I think the missing space should be fixed to :)
> > > > > > +1 to the missing space.
> > > > > This one is confusing - it isn't in my local diff, the raw diff, or if I reapply the raw diff - it looks to have just appeared when you quote it in phab comments?
> > > > The fact that the space is missing? It's missing in the current repo too.
> > > It works with and without the space, like `-GNinja` and `-G Ninja` both work.
> > It would be nice to mention the CMake minimum version.  I think that you need 3.22 or newer for the 2022 generator/toolset definition.
> It works with or without the space, but it reads better with the space.
We should probably drop the space issue: I noticed further down that it doesn't have a space in either for e.g. Ninja. Don't mind either way though.


================
Comment at: clang/docs/UsersManual.rst:3546
 
-    cmake -G"Visual Studio 15 2017" -T LLVM ..
+    cmake -G"Visual Studio 16 2019" -T LLVM ..
 
----------------
stella.stamenova wrote:
> jhenderson wrote:
> > Maybe make this VS2022 instead, to help it last longer?
> I think it makes more sense to make it 2019 because I expect most people to still be using 2019 and it's convenient to have instructions that just work. Maybe add both?
No objections either way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D114639/new/

https://reviews.llvm.org/D114639