Project

General

Profile

Feature #3952

Add Visual Studio 2017 support

Added by Lennart Bernhardt 4 months ago. Updated 4 months ago.

Status:
Closed
Priority:
Normal
Category:
General
Target version:
Start date:
07/11/2017
% Done:

0%

Severity:
Normal

Description

It's out of RC phase now so it would be awesome to be able to use the latest tools.
I'd do it myself but I'm not familiar with cmake stuffs on windows and how that already supports creating projects for vs 2017.

Associated revisions

Revision c23b75ab
Added by scrawl . 4 months ago

Merge pull request #1339 from PlutonicOverkill/vs2017-support

Add Visual Studio 2017 support (Feature #3952)

History

#1 Updated by Haoda Wang 4 months ago

CLion works perfectly well with the CMake files.

Does opening the folder as a project work?

#2 Updated by Lennart Bernhardt 4 months ago

Everything does work fine, that's why this is a feature.
Basically on windows you need to generate different project files for different versions of Visual Studio. Right now there is only support for vs2013 and 2015 in the build scripts.
Adding support for vs 2017 in the build scripts would remove the need to upgrade projects.

#3 Updated by Plutonic Overkill 4 months ago

This issue doesn't really have anything to do with CMake or the build scripts, it's just that binaries from different compiler versions aren't compatible with one another, and most libraries still don't have prebuilt VS 2017 binaries (the build script uses mainly these binaries). AFAIK, OpenMW will still build on VS 2017, but you'll need to build all the dependencies yourself (a tedious process on Windows). To add proper support, these binaries would need to be hosted somewhere so they could be downloaded by the build script.

#4 Updated by Plutonic Overkill 4 months ago

Wow, turns out that VS 2017 is binary compatible with VS 2015 after all; it builds fine using the same project file. Looks like I'll be using VS 2017 for OpenMW from now on.

#5 Updated by Haoda Wang 4 months ago

So can we mark this as resolved...?

#6 Updated by Lennart Bernhardt 4 months ago

No as you still need to manually upgrade the project files. Would be nice if it just generated the project files for 2017 directly

#7 Updated by Plutonic Overkill 4 months ago

https://github.com/PlutonicOverkill/openmw/commit/2d7689b978444eef07f8a893b78da2d9cb1214fc
Done a quick implementation and it seems to work so far. Haven't tested it yet for VS2013 or VS2015 but they should work OK.

#8 Updated by Lennart Bernhardt 4 months ago

It should be v141 for vs2017

#9 Updated by Plutonic Overkill 4 months ago

Does it make any difference? TOOLSET and XP_TOOLSET don't seem to be used anywhere, and BOOST_TOOLSET is only used because the Boost binaries only have v140 versions.

#10 Updated by Lennart Bernhardt 4 months ago

When I upgraded the solutions manually it I set to v141 and it compiled fine https://vgy.me/mmWsMs.png

#11 Updated by Plutonic Overkill 4 months ago

Yes, but it doesn't matter here. The toolset is automatically chosen as v141 based on the generator used (Visual Studio 15 2017).

#12 Updated by Lennart Bernhardt 4 months ago

awesome!

#13 Updated by Plutonic Overkill 4 months ago

I've just come across another case that I hadn't considered before, where this feature would be useful. Whenever CMakeLists.txt is modified, CMake has to re-run, using whatever generator was specified to it the first time around. This means that if the project files were manually upgraded, they'll be regenerated, and you'll have to upgrade them again every time you change the CMakeLists.txt file.

#14 Updated by Alexei Dobrohotov 4 months ago

  • Category set to General
  • Status changed from New to Resolved
  • Assignee set to Plutonic Overkill
  • Target version set to openmw-0.43

#15 Updated by Alexei Dobrohotov 4 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF