windows: Make msvc project file support any version from VS2013 to VS…#2968
windows: Make msvc project file support any version from VS2013 to VS…#2968stinos wants to merge 1 commit intomicropython:masterfrom
Conversation
…2017 Instead of having the PlatformToolset property hardcoded to a specific version just set it to the value of DefaultPlatformToolset: this gets defined according to the commandline environment in which the build was started. Instead of just supporting VS2015 the project can now be built by any version from VS2013 to VS2017 and normally future versions as well, without quirks like VS asking whether you want to upgrade the project to the latest version (as was the case when opening the project in VS2017) or not being able to build at all (as was the case when opening the project in VS2013). Also adjust the .gitignore file to ignore any artefacts from VS2017.
|
Wouldn't the point of having a hard-coded version be to indicate that the build files only support a specific version (because that's the version they were written for)? By making it match any version of the compiler you're bypassing this check, and will need to ensure that all config options are supported by all versions. I mean, I guess that's ok if they are indeed supported, and I guess you are submitting this PR because this is the correct way to support multiple versions of VS. Right? |
Yes that's the point, but in this case the build files work for at least 3 different toolsets without any modification (except for that version number). And even if there would be a need for different options for the compiler or so per version, it would still be better to deal with this as such (e.g. have a condition on the version and select options accordingly, instead of just duplicating build files and changing just version number and compiler option whereas the rest of the files remains the same; as many many other projects do unfortunately)
The windows/README states that at least VS2013 is required (this is also checked when building) and no compiler flags affecting uPy were changed since that version so I consider everything covered; I also verified this, all builds from all versions build&test fine.
In my opinion it this: for projects like this it works without problems, though it is not widely used. I assume that is simply because not many people know it can be done like this due to lack of explicit documentation (I also only found out a couple of months ago) and because they are spoiled by using a UI to deal with the build configuration and as such are reluctant to editing the files by hand. |
|
Thanks for the explanation! Rebased and merged in c611313 |
…ation More efficient translation
2 participants
…2017
Instead of having the PlatformToolset property hardcoded to a specific
version just set it to the value of DefaultPlatformToolset: this gets
defined according to the commandline environment in which the build was
started.
Instead of just supporting VS2015 the project can now be built by any
version from VS2013 to VS2017 and normally future versions as well, without
quirks like VS asking whether you want to upgrade the project to the latest
version (as was the case when opening the project in VS2017) or not being
able to build at all (as was the case when opening the project in VS2013).
Also adjust the .gitignore file to ignore any artefacts from VS2017.
Technically VS2012/VS2010 are supported like this as well but I didn't test this and I'm pretty sure their compiler lacks the needed C99 support anyway.