djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e160fe7bc6
circuitpython/ports/windows/msvc/common.props

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

66 lines
3.6 KiB
Plaintext
Raw Normal View History

Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
windows: Add support for build variants to windows port. Following the unix port. Support for building variants with msvc was done by @stinos.
2021-11-24 20:16:29 -05:00
<!-- Variant support. For compatibility with how it works for the other ports, this gets imported
early so variants cannot override build options like the ones specified in the rest of this file.
Use CustomPropsFile (see the .vcxproj file) for that. -->
windows/msvc: Make mpy-cross independent of micropython variant. The variant.props may have incompatible build options which break the mpy-cross build and in any case mpy-cross has nothing to do with variant support.
2023-01-24 04:56:26 -05:00
<PropertyGroup Condition="'$(PyBuildingMpyCross)' != 'True'">
windows: Add support for build variants to windows port. Following the unix port. Support for building variants with msvc was done by @stinos.
2021-11-24 20:16:29 -05:00
<PyVariant Condition="'$(PyVariant)' == ''">standard</PyVariant>
<PyBuild Condition="'$(PyBuild)' == ''">build-$(PyVariant)</PyBuild>
windows/msvc: Remove variant suffix from executable filename. This is in line with the change made for other ports in d53c3b6a: since the default output directory already includes the variant name in it there's no need to add it to the executable as well.
2023-01-23 05:33:27 -05:00
<PyProg Condition="'$(PyProg)' == ''">micropython</PyProg>
windows: Add support for build variants to windows port. Following the unix port. Support for building variants with msvc was done by @stinos.
2021-11-24 20:16:29 -05:00
</PropertyGroup>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
<ImportGroup Label="PropertySheets">
msvc: Use different output directories depending on build type This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)
2015-11-12 03:42:12 -05:00
<Import Project="paths.props" Condition="'$(PyPathsIncluded)' != 'True'"/>
windows/msvc: Make mpy-cross independent of micropython variant. The variant.props may have incompatible build options which break the mpy-cross build and in any case mpy-cross has nothing to do with variant support.
2023-01-24 04:56:26 -05:00
<Import Condition="'$(PyBuildingMpyCross)' != 'True'" Project="$(PyVariantDir)mpconfigvariant.props"/>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<OutDir>$(PyOutDir)</OutDir>
msvc: Use different output directories depending on build type This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)
2015-11-12 03:42:12 -05:00
<IntDir>$(PyIntDir)</IntDir>
<PyFileCopyCookie>$(PyBuildDir)copycookie$(Configuration)$(Platform)</PyFileCopyCookie>
windows/msvc: Move build options from .vcxproj to .props files. We want the .vcxproj to be just a container with the minimum content for making it work as a project file for Visual Studio and MSBuild, whereas the actual build options and actions get placed in separate reusable files. This was roughly the case already except some compiler options were overlooked; fix this here: we'll need those common options when adding a project file for building mpy-cross.
2017-08-11 09:33:39 -04:00
<CharacterSet>MultiByte</CharacterSet>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<AdditionalIncludeDirectories>$(PyIncDirs);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
windows/msvc: Fix warnings regarding function declarations. Fix missing mkdir and gettimeofday declarations, then silence msvc-specific compiler warning C4996: 'The POSIX name for this item is deprecated'.
2020-03-20 06:00:41 -04:00
<PreprocessorDefinitions>_USE_MATH_DEFINES;_CRT_SECURE_NO_WARNINGS;_CRT_NONSTDC_NO_WARNINGS;_MBCS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
<SDLCheck>false</SDLCheck>
<WarningLevel>Level1</WarningLevel>
<ExceptionHandling>false</ExceptionHandling>
windows: Enable multi-processor compilation for msvc This will launch about as many compiler instances as there are logical processors on a machine, and as such significantly speeds up compilation.
2016-04-27 10:00:41 -04:00
<MultiProcessorCompilation>true</MultiProcessorCompilation>
<MinimalRebuild>false</MinimalRebuild>
windows/msvc: Treat compiler warnings as errors. This is consistent with the other ports and helps catching problems early.
2019-09-03 04:08:03 -04:00
<TreatWarningAsError>true</TreatWarningAsError>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
</ClCompile>
<Link>
<GenerateDebugInformation>true</GenerateDebugInformation>
<GenerateMapFile>true</GenerateMapFile>
windows: Use BCryptGenRandom to implement os.urandom. Fix urandom not working on windows (there's no /dev/urandom) by using a proper cryptographic random function (same one as CPython >= 3.11).
2022-06-07 05:24:42 -04:00
<AdditionalDependencies>Bcrypt.lib;%(AdditionalDependencies)</AdditionalDependencies>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
</Link>
</ItemDefinitionGroup>
msvc: Use different output directories depending on build type This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)
2015-11-12 03:42:12 -05:00
<ItemGroup>
<PyOutputFiles Include="$(TargetPath)">
windows/msvc: Enable overriding directories used in the build. Append to PyIncDirs, used to define include directories specific to MicroPython, instead of just overwriting it so project files importing this file can define additional directories. And allow defining the target directory for the executable instead of hardcoding it to the windows directory. Main reason for this change is that it will allow building mpy-cross with msvc.
2017-08-14 06:12:30 -04:00
<Destination>$(PyTargetDir)%(FileName)%(Extension)</Destination>
msvc: Use different output directories depending on build type This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)
2015-11-12 03:42:12 -05:00
</PyOutputFiles>
<PyCookieFiles Include="$(PyBuildDir)copycookie*" Exclude="$(PyFileCopyCookie)"/>
windows: Add support for build variants to windows port. Following the unix port. Support for building variants with msvc was done by @stinos.
2021-11-24 20:16:29 -05:00
<QstrDependencies Include="$(PyVariantDir)mpconfigvariant.h"/>
msvc: Use different output directories depending on build type This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)
2015-11-12 03:42:12 -05:00
</ItemGroup>
windows/appveyor: Build both standard and dev variants. This makes sure changes from previous related commits actually work.
2021-11-25 10:50:10 -05:00
<!-- Helper for getting resulting executable path since it depends on other properties. -->
<Target Name="ShowTargetPath">
<Message Text="$(TargetPath)" Importance="high"/>
</Target>
msvc: Use different output directories depending on build type This allows multiple versions (e.g. Debug/Release, x86/x64) of micropython.exe to co-exist instead and also solves potential problems where msbuild does not completely rebuild the output and/or pdb files when switching between builds, which in turn can cause linker errors in dependent projects. By default exe/map/... files go in windows/build/$(Configuration)$(Platform) After each build micropython.exe is still copied from the above directory to the windows directory though, as that is consistent with the other ports and the test runner by default uses that location as well. Also rename env.props -> path.props which is a clearer name, and add ample documentation in the affected build files. (also see discussion in #1538)
2015-11-12 03:42:12 -05:00
<!-- Copy PyOutputFiles to their target destination.
To force this when switching between platforms/configurations which are already up-to-date (and as such,
for which a build wouldn't even start because all outputs are effectively newer than the inputs)
an empty file $(PyFileCopyCookie) is created serving as a record to indicate what was last copied,
and any previous records are deleted. So when switching between builds which are otherwise up-to-date
the tracker will notice a missing file and a build is started anyway (and it will just copy our files). -->
<Target Name="CopyFilesToWinDir" AfterTargets="Build"
Inputs="$(TargetPath)" Outputs="$(PyFileCopyCookie);@(PyOutputFiles->'%(Destination)')">
<Delete Files="@(PyCookieFiles)"/>
<Touch Files="$(PyFileCopyCookie)" AlwaysCreate="true"/>
<Copy SourceFiles="%(PyOutputFiles.Identity)" DestinationFiles="%(PyOutputFiles.Destination)"/>
<WriteLinesToFile File="$(TLogLocation)$(ProjectName).write.u.tlog" Lines="$(PyFileCopyCookie);@(PyOutputFiles->'%(Destination)')" Overwrite="True"/>
</Target>
Add .gitattributes file to force text line endings to LF. Some files are excluded, otherwise a whole lot of files need converting.
2015-04-16 17:19:50 -04:00
</Project>
Reference in New Issue Copy Permalink