8000 Fix project build for VS2015 by omtinez · Pull Request #1538 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Fix project build for VS2015 #1538

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Fix project build for VS2015 #1538

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions windows/micropython.vcxproj
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, along with PlatformToolset, will make the project file unusable for earlier versions of VS (i.e. 2013). I knew the day would come we'd need to take care of dealing with muliple versions of VS (which is why the meat of the configuration is already in seperate .props files and the project is just a 'container' now) but never put much thought into how to do this exactly. Do you have any suggestions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The usual methodology is to keep this up to date with the latest version and the project members that still have an older one need to change this file by hand prior to opening the project and exclude their project files from their commits. It's unfortunate that VS does not handle this scenario better, specially considering that newer versions can typically open an older solution and the changes occur automatically.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it not make more sense to just support the oldest version then, since upgrading can be done automatically and effortless?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This, along with PlatformToolset, will make the project file unusable for earlier versions of VS (i.e. 2013).

Nevermind, seems I was wrong all along: opening the upgraded project in VS2013 just uses the v120 platformtoolset automatically so that worked out flawlessly after all..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you can just double click the project file and it opens in Visual Studio 2013 just fine? That's news to me. Did it prompt you that the project could not be loaded? Did it prompt you to convert the project to a compatible VS version? Did the project file change to v120 everywhere after opening it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you can just double click the project file and it opens in Visual Studio 2013 just fine?

Only if VS2015 is not installed, else you have to explicitely open in VS2013, but in any case it works ok on the 2 machines I tried it on. No prompt for downgrading, no changes to the project file. It's news to me as well, in fact I'm sure tons of people out there have no idea, but it's good news.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be the other way around - newer version of IDE should be able to open project files from older version without problems?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not the case, and other IDE's present the same issue (Android Studio comes to mind). Newer version of the IDE tries to convert the project to the latest version, if possible in a backwards-compatible way. Depending on the project type and version diff, converting the project might fail or it may end up being incompatible with older versions of the IDE.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not the case, and other IDE's present the same issue

How is that problem of the individual projects, MicroPython in this case? That's bug in the IDE, it should be reported to its vendor, and resolved on its side.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Project templates/settings change, not always in a compatible way. It's not a bug, it's a breaking change. In this case, all settings being exposed in the vcxproj of this project appear to be compatible between versions and the transition is seamless. Not all project types are the same, and the breaking changes are specially common in mobile application project types or unstable/beta types such as pyproj.

<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
Expand All @@ -26,26 +26,26 @@
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>true</UseDebugLibraries>
<PlatformToolset>v120</PlatformToolset>
<PlatformToolset>v140</PlatformToolset>
<CharacterSet>MultiByte</CharacterSet>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v120</PlatformToolset>
<PlatformToolset>v140</PlatformToolset>
<WholeProgramOptimization>true</WholeProgramOptimization>
<CharacterSet>MultiByte</CharacterSet>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>true</UseDebugLibraries>
<PlatformToolset>v120</PlatformToolset>
<PlatformToolset>v140</PlatformToolset>
<CharacterSet>MultiByte</CharacterSet>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
<UseDebugLibraries>false</UseDebugLibraries>
<PlatformToolset>v120</PlatformToolset>
<PlatformToolset>v140</PlatformToolset>
<WholeProgramOptimization>true</WholeProgramOptimization>
<CharacterSet>MultiByte</CharacterSet>
</PropertyGroup>
Expand Down Expand Up @@ -75,7 +75,6 @@
<PropertyGroup Label="UserMacros">
<CustomPropsFile Condition="'$(CustomPropsFile)'==''">msvc/user.props</CustomPropsFile>
</PropertyGroup>
<PropertyGroup />
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<ClCompile />
<Link />
Expand All @@ -102,4 +101,4 @@
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
</Project>
</Project>
0