djsundog
/
circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
circuitpython/ports/windows/micropython.vcxproj

112 lines
5.6 KiB
XML
Raw Normal View History

Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
<?xml version="1.0" encoding="utf-8"?>
Fix project file for Visual Studio 2015
2015-11-09 17:56:57 -05:00
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
<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>
</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.
2017-03-20 11:15:46 -04:00
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
</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.
2017-03-20 11:15:46 -04:00
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
</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.
2017-03-20 11:15:46 -04:00
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
</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.
2017-03-20 11:15:46 -04:00
<PlatformToolset>$(DefaultPlatformToolset)</PlatformToolset>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
</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's home directory - make git ignore the file
2015-04-30 04:14:59 -04:00
<PropertyGroup Label="UserMacros">
<CustomPropsFile Condition="'$(CustomPropsFile)'==''">msvc/user.props</CustomPropsFile>
</PropertyGroup>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
<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.
2017-08-16 04:32:47 -04:00
<Import Project="msvc/sources.props" />
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 06:18:27 -04:00
<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.
2017-08-16 04:32:47 -04:00
<ClCompile Include="@(PyCoreSource)" />
<ClCompile Include="@(PyExtModSource)" />
<ClCompile Include="$(PyBaseDir)lib\mp-readline\*.c" />
all: Factor gchelper code to one place and use it for unix & ARM ports. No functionality change is intended with this commit, it just consolidates the separate implementations of GC helper code to the lib/utils/ directory as a general set of helper functions useful for any port. This reduces duplication of code, and makes it easier for future ports or embedders to get the GC implementation correct. Ports should now link against gchelper_native.c and either gchelper_m0.s or gchelper_m3.s (currently only Cortex-M is supported but other architectures can follow), or use the fallback gchelper_generic.c which will work on x86/x64/ARM. The gc_helper_get_sp function from gchelper_m3.s is not really GC related and was only used by cc3200, so it has been moved to that port and renamed to cortex_m3_get_sp.
2020-04-23 02:12:55 -04:00
<ClCompile Include="$(PyBaseDir)lib\utils\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.
2017-08-16 04:32:47 -04:00
<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\modos.c"/>
<ClCompile Include="$(PyBaseDir)ports\unix\modtime.c"/>
<ClCompile Include="$(PyBaseDir)ports\unix\modmachine.c" />
</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
2014-05-05 06:18:27 -04:00
</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's home directory - make git ignore the file
2015-04-30 04:14:59 -04:00
<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.
2020-09-10 06:11:58 -04:00
<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
2014-05-05 06:18:27 -04:00
</Target>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
Fix project file for Visual Studio 2015
2015-11-09 17:56:57 -05:00
</Project>