github
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
14685 Commits
3 Branches
62 Tags
504 MiB
Tree: 8f8bd98164
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8f8bd98164'
${ noResults }
micropython/ports/windows/micropython.vcxproj

114 lines
5.6 KiB
Raw Normal View History

Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
<?xml version="1.0" encoding="utf-8"?>
windows: Unify project file headers. The xmlns attribute is required for older msbuild version (e.g. for VS2015). Add it where needed, and reorder the attributes so all files look the same.
3 years ago
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0" DefaultTargets="Build">
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|Win32">
<Configuration>Debug</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|Win32">
<Configuration>Release</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{740F3C30-EB6C-4B59-9C50-AE4D5A4A9D12}</ProjectGuid>
<RootNamespace>micropython</RootNamespace>
windows: Make project file read-only for IDE. Avoids the &#39;warning: Wildcards in project items are not supported&#39; message from the C++ project system in Visual Studio, while otherwise remaining completely functional.
2 years ago
<ReadOnlyProject>true</ReadOnlyProject>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
windows: Make msvc project file support any version from VS2013 to VS2017 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.
8 years ago
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
windows: Make msvc project file support any version from VS2013 to VS2017 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.
8 years ago
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
windows: Make msvc project file support any version from VS2013 to VS2017 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.
8 years ago
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>Application</ConfigurationType>
windows: Make msvc project file support any version from VS2013 to VS2017 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.
8 years ago
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="msvc/common.props" />
<Import Project="msvc/debug.props" />
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="msvc/common.props" />
<Import Project="msvc/release.props" />
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="msvc/common.props" />
<Import Project="msvc/debug.props" />
</ImportGroup>
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="msvc/common.props" />
<Import Project="msvc/release.props" />
</ImportGroup>
msvc: Allow overriding of build options with custom file - by default look for a user.props in the msvc directory, which is more convenient than the built-in way of looking for such file in the user&#39;s home directory - make git ignore the file
10 years ago
<PropertyGroup Label="UserMacros">
<CustomPropsFile Condition="'$(CustomPropsFile)'==''">msvc/user.props</CustomPropsFile>
windows: Add support for build variants to windows port. Following the unix port. Support for building variants with msvc was done by @stinos.
3 years ago
<TargetName>$(PyProg)</TargetName>
msvc: Allow overriding of build options with custom file - by default look for a user.props in the msvc directory, which is more convenient than the built-in way of looking for such file in the user&#39;s home directory - make git ignore the file
10 years ago
</PropertyGroup>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<ClCompile />
<Link />
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ClCompile />
<Link />
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<ClCompile />
<Link />
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ClCompile />
<Link />
</ItemDefinitionGroup>
windows/msvc: Change the way sources are listed. Reserve sources.props for listing just the MicroPython core and extmod files, similar to how py.mk lists port-independent source files. This allows reusing the source list, for instance for building mpy-cross. The sources for building the executable itself are listed in the corresponding project file, similar to how the other ports specify the source files in their Makefile.
7 years ago
<Import Project="msvc/sources.props" />
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
<ItemGroup>
windows/msvc: Change the way sources are listed. Reserve sources.props for listing just the MicroPython core and extmod files, similar to how py.mk lists port-independent source files. This allows reusing the source list, for instance for building mpy-cross. The sources for building the executable itself are listed in the corresponding project file, similar to how the other ports specify the source files in their Makefile.
7 years ago
<ClCompile Include="@(PyCoreSource)" />
<ClCompile Include="@(PyExtModSource)" />
all: Update to point to files in new shared/ directory. Signed-off-by: Damien George &lt;damien@micropython.org&gt;
3 years ago
<ClCompile Include="$(PyBaseDir)shared\readline\*.c" />
<ClCompile Include="$(PyBaseDir)shared\runtime\gchelper_generic.c" />
windows/msvc: Change the way sources are listed. Reserve sources.props for listing just the MicroPython core and extmod files, similar to how py.mk lists port-independent source files. This allows reusing the source list, for instance for building mpy-cross. The sources for building the executable itself are listed in the corresponding project file, similar to how the other ports specify the source files in their Makefile.
7 years ago
<ClCompile Include="$(PyBaseDir)ports\windows\*.c" />
<ClCompile Include="$(PyBaseDir)ports\windows\msvc\*.c" />
<ClCompile Include="$(PyBaseDir)ports\unix\gccollect.c"/>
<ClCompile Include="$(PyBaseDir)ports\unix\input.c"/>
<ClCompile Include="$(PyBaseDir)ports\unix\main.c"/>
<ClCompile Include="$(PyBaseDir)ports\unix\modmachine.c" />
windows: Add support for build variants to windows port. Following the unix port. Support for building variants with msvc was done by @stinos.
3 years ago
<ClCompile Include="$(PyVariantDir)*.c" />
windows/msvc: Change the way sources are listed. Reserve sources.props for listing just the MicroPython core and extmod files, similar to how py.mk lists port-independent source files. This allows reusing the source list, for instance for building mpy-cross. The sources for building the executable itself are listed in the corresponding project file, similar to how the other ports specify the source files in their Makefile.
7 years ago
</ItemGroup>
<ItemGroup>
<ClInclude Include="@(PyCoreInclude)" />
<ClInclude Include="@(PyExtModInclude)" />
<ClInclude Include="$(PyBaseDir)ports\windows\*.h" />
<ClInclude Include="$(PyBaseDir)ports\windows\msvc\*.h" />
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</ItemGroup>
<Import Project="msvc/genhdr.targets" />
msvc: Allow overriding of build options with custom file - by default look for a user.props in the msvc directory, which is more convenient than the built-in way of looking for such file in the user&#39;s home directory - make git ignore the file
10 years ago
<Import Project="$(CustomPropsFile)" Condition="exists('$(CustomPropsFile)')" />
windows/msvc: Support freezing modules. Support freezing modules via manifest.py for consistency with the other ports. In essence this comes down to calling makemanifest.py and adding the resulting .c file to the build. Note the file with preprocessed qstrs has been renamed to match what makemanifest.py expects and which is also the name all other ports use.
4 years ago
<Target Name="GenerateMicroPythonSources" BeforeTargets="BuildGenerateSources" DependsOnTargets="GenerateHeaders;FreezeModules">
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
11 years ago
</Target>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
all: Update to point to files in new shared/ directory. Signed-off-by: Damien George &lt;damien@micropython.org&gt;
3 years ago
</Project>