djsundog
/
circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
circuitpython/ports/windows/msvc/genhdr.targets

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

161 lines
8.9 KiB
Plaintext
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"?>
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.
2022-02-22 09:42:50 -05:00
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="14.0" DefaultTargets="GenerateHeaders">
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
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'"/>
msvc: Define main build/include directories in a single location - Use a single file env.props for defining the main directories used when building. env.props resolves the base directory and defines overridable output directories, and is used by all other build files. - Fix the build currently failing, basically because the preprocessing command for generating qstrdefs uses different include directories than the build itself does. (specifically, qstrdefs.h uses #include "py/mpconfig.h" since the fixes for #1022 in 51dfcb4, so we need to use the base directory as include directory, not the py dir itself). So define a single variable containing the include directories instead and use it where needed.
2015-01-02 05:49:23 -05:00
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<!--Generate qstrdefs.generated.h and mpversion.h similar to what is done in py/mkrules.mk and py/py.mk-->
py: Allow registration of modules at their definition. During make, makemoduledefs.py parses the current builds c files for MP_REGISTER_MODULE(module_name, obj_module, enabled_define) These are used to generate a header with the required entries for "mp_rom_map_elem_t mp_builtin_module_table[]" in py/objmodule.c
2019-02-17 22:58:44 -05:00
<Target Name="GenerateHeaders" DependsOnTargets="MakeVersionHdr;MakeModuleDefs;MakeQstrData">
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>
<PropertyGroup>
msvc: Define main build/include directories in a single location - Use a single file env.props for defining the main directories used when building. env.props resolves the base directory and defines overridable output directories, and is used by all other build files. - Fix the build currently failing, basically because the preprocessing command for generating qstrdefs uses different include directories than the build itself does. (specifically, qstrdefs.h uses #include "py/mpconfig.h" since the fixes for #1022 in 51dfcb4, so we need to use the base directory as include directory, not the py dir itself). So define a single variable containing the include directories instead and use it where needed.
2015-01-02 05:49:23 -05:00
<DestDir>$(PyBuildDir)genhdr\</DestDir>
py: Replace py-version.sh with makeversionhdr.py, written in Python. Also rename py-version.h to mpversion.h for consistency with mpconfig.h.
2015-04-22 12:38:05 -04:00
<PySrcDir>$(PyBaseDir)py\</PySrcDir>
all: Update Makefiles and others to build with new ports/ dir layout. Also renames "stmhal" to "stm32" in documentation and everywhere else.
2017-09-06 00:09:13 -04:00
<QstrDefs>$(PyBaseDir)ports\unix\qstrdefsport.h</QstrDefs>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<PyQstrDefs>$(PySrcDir)qstrdefs.h</PyQstrDefs>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
<QstrDefsCollected>$(DestDir)qstrdefscollected.h</QstrDefsCollected>
<QstrGen>$(DestDir)qstrdefs.generated.h</QstrGen>
windows/msvc: Use same default python command as core.
2021-01-16 03:01:17 -05:00
<PyPython Condition="'$(PyPython)' == ''">$(MICROPY_CPYTHON3)</PyPython>
windows: Allow specifying the python executable to use for msvc builds This defaults to 'python' but can be now overridden if needed
2015-11-07 14:00:26 -05:00
<PyPython Condition="'$(PyPython)' == ''">python</PyPython>
windows/msvc: Support custom compiler for header generation. Use overrideable properties instead of hardcoding the use of the default cl executable used by msvc toolsets. This allows using arbitrary compiler commands for qstr header generation. The CLToolExe and CLToolPath properties are used because they are, even though absent from any official documentation, the de-facto standard as used by the msvc toolsets themselves.
2018-07-24 07:29:03 -04:00
<CLToolExe Condition="'$(CLToolExe)' == ''">cl.exe</CLToolExe>
<PyClTool>$([System.IO.Path]::Combine(`$(CLToolPath)`, `$(CLToolExe)`))</PyClTool>
windows/msvc: Run qstr preprocessing phase in parallel. Supported from VS2017 and up, this roughly halves build time.
2022-01-12 07:57:41 -05:00
<PyPlatformToolsetNum>120</PyPlatformToolsetNum> <!--Minimum we support is VS2013.-->
<PyPlatformToolsetNum Condition="$(PlatformToolset.StartsWith('v'))">$(PlatformToolset.Replace('v', ''))</PyPlatformToolsetNum>
<PyParallelPreProc Condition="'$(PyPlatformToolsetNum)' &gt; '140'">True</PyParallelPreProc> <!--VS2017 and up.-->
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>
windows/msvc: Run qstr preprocessing phase in parallel. Supported from VS2017 and up, this roughly halves build time.
2022-01-12 07:57:41 -05:00
<UsingTask Condition="'$(PyParallelPreProc)' == 'True'"
TaskName="ParallelCustomBuild" AssemblyFile="$(VCTargetsPath)\Microsoft.Build.CppTasks.Common.dll"/>
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 Name="MakeDestDir">
<MakeDir Directories="$(DestDir)"/>
</Target>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<!-- Concatenate preprocessed files for use with makeqstrdefs.py.
Filters out any lines which aren't used by makeqstrdefs.py so the resulting file is
hundreds of times smaller and processing in python takes substantially less time-->
<UsingTask TaskName="ConcatPreProcFiles" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
<ParameterGroup>
<OutputFile Required="true" ParameterType="System.String"/>
<InputFiles Required="true" ParameterType="System.String[]"/>
</ParameterGroup>
<Task>
<Code Type="Fragment" Language="cs">
<![CDATA[
using(var outFile = System.IO.File.CreateText(OutputFile)) {
foreach(var inFile in InputFiles)
foreach(var line in System.IO.File.ReadAllLines(inFile))
if((line.Contains(".c") && line.StartsWith("#line")) || line.Contains("MP_QSTR"))
outFile.WriteLine( line );
}
]]>
</Code>
</Task>
</UsingTask>
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
<!-- If any of these changed we'll force all qstrs to be generated again-->
<ItemGroup>
<QstrDependencies Include="$(PyWinDir)mpconfigport.h;$(PySrcDir)mpconfig.h;$(PySrcDir)makeqstrdata.py"/>
</ItemGroup>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<!-- Preprocess changed files, concatenate and feed into makeqstrdefs.py split/cat-->
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
<Target Name="MakeQstrDefs" DependsOnTargets="MakeDestDir" Inputs="@(ClCompile);@(QstrDependencies)" Outputs="$(QstrDefsCollected)">
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
<ItemGroup>
<PyIncDirs Include="$(PyIncDirs)"/>
windows/msvc: Remove unneeded definitions for qstr generation. These were probably added to detect more qstrs but as long as the micropython executable itself doesn't use the same build options the qstrs would be unused anyway. Furthermore these definitions are for internal use and get enabled when corresponding MICROPY_EMIT_XXX are defined, in which case the compiler would warn about symbol redefinitions since they'd be defined both here and in the source.
2019-05-29 11:14:45 -04:00
<PreProcDefs Include="%(ClCompile.PreProcessorDefinitions);NO_QSTR"/>
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
<PyQstrSourceFiles Include="@(ClCompile)" Exclude="$(PyBuildDir)\frozen_content.c">
windows/msvc: Run qstr preprocessing phase in parallel. Supported from VS2017 and up, this roughly halves build time.
2022-01-12 07:57:41 -05:00
<Changed>False</Changed>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<OutFile>$([System.String]::new('%(FullPath)').Replace('$(PyBaseDir)', '$(DestDir)qstr\'))</OutFile>
</PyQstrSourceFiles>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
<PyQstrSourceFiles>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<OutFile>$([System.IO.Path]::ChangeExtension('%(OutFile)', '.pp'))</OutFile>
<OutDir>$([System.IO.Path]::GetDirectoryName('%(OutFile)'))</OutDir>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
</PyQstrSourceFiles>
<PyQstrSourceFiles>
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
<Changed Condition="$([System.DateTime]::Compare($([System.IO.File]::GetLastWriteTime('%(FullPath)')), $([System.IO.File]::GetLastWriteTime('%(OutFile)')))) &gt; 0">True</Changed>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
</PyQstrSourceFiles>
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
<QstrDependencies>
<Changed Condition="$([System.DateTime]::Compare($([System.IO.File]::GetLastWriteTime('%(FullPath)')), $([System.IO.File]::GetLastWriteTime('$(DestDir)qstr.i.last')))) &gt; 0">True</Changed>
</QstrDependencies>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
</ItemGroup>
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
<PropertyGroup>
windows/msvc: Run qstr preprocessing phase in parallel. Supported from VS2017 and up, this roughly halves build time.
2022-01-12 07:57:41 -05:00
<PyPreProcCommand>$(PyClTool) /nologo /I@(PyIncDirs, ' /I') /D@(PreProcDefs, ' /D')</PyPreProcCommand>
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
<ForceQstrRebuild>@(QstrDependencies->AnyHaveMetadataValue('Changed', 'True'))</ForceQstrRebuild>
msvc: Workaround parser bug in older MSBuild versions Versions prior to v14.0 have a bug in parsing item functions when used within a condition: https://github.com/Microsoft/msbuild/issues/368. Since commit [db9c2e3] this results in an error when building MicroPython with for example VS2013. Fix this by creating an intermediate property.
2017-05-01 04:50:58 -04:00
<RunPreProcConcat>@(PyQstrSourceFiles->AnyHaveMetadataValue('Changed', 'True'))</RunPreProcConcat>
msvc: Rebuild all qstrs when mpconfig headers are modified Make qstr generation depend on modifications in mpconfigport.h, mpconfig.h and makeqstrdata.py and if any of those change scan all source files for qstrs again since they might have changed (for example typcially when enabling new features in mpconfig.h). This fixes #2982 for msvc builds.
2017-04-03 07:16:12 -04:00
</PropertyGroup>
windows/msvc: Run qstr preprocessing phase in parallel. Supported from VS2017 and up, this roughly halves build time.
2022-01-12 07:57:41 -05:00
<ItemGroup>
<PyQstrSourceFilesToPreProc Include="@(PyQstrSourceFiles)" Condition="'%(Changed)' == 'True' Or '$(ForceQstrRebuild)' == 'True'">
<Command>$(PyPreProcCommand) /Fi%(OutFile) /P %(Identity)</Command>
<Outputs>%(OutFile)</Outputs>
</PyQstrSourceFilesToPreProc>
</ItemGroup>
<MakeDir Directories="@(PyQstrSourceFilesToPreProc->'%(OutDir)')"/>
<Exec Condition="'$(PyParallelPreProc)' != 'True'" Command="%(PyQstrSourceFilesToPreProc.Command)" />
<ParallelCustomBuild Condition="'$(PyParallelPreProc)' == 'True' And '@(PyQstrSourceFilesToPreProc)' != ''" Sources="@(PyQstrSourceFilesToPreProc)" />
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<ConcatPreProcFiles InputFiles="@(PyQstrSourceFiles->'%(OutFile)')" OutputFile="$(DestDir)qstr.i.last"
msvc: Workaround parser bug in older MSBuild versions Versions prior to v14.0 have a bug in parsing item functions when used within a condition: https://github.com/Microsoft/msbuild/issues/368. Since commit [db9c2e3] this results in an error when building MicroPython with for example VS2013. Fix this by creating an intermediate property.
2017-05-01 04:50:58 -04:00
Condition="'$(RunPreProcConcat)' == 'True' Or '$(ForceQstrRebuild)' == 'True'"/>
windows: Update genhdr.targets to match makeqstrdefs.py args.
2020-03-04 06:11:39 -05:00
<Exec Command="$(PyPython) $(PySrcDir)makeqstrdefs.py split qstr $(DestDir)qstr.i.last $(DestDir)qstr _"/>
<Exec Command="$(PyPython) $(PySrcDir)makeqstrdefs.py cat qstr _ $(DestDir)qstr $(QstrDefsCollected)"/>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
</Target>
py: Allow registration of modules at their definition. During make, makemoduledefs.py parses the current builds c files for MP_REGISTER_MODULE(module_name, obj_module, enabled_define) These are used to generate a header with the required entries for "mp_rom_map_elem_t mp_builtin_module_table[]" in py/objmodule.c
2019-02-17 22:58:44 -05:00
<Target Name="MakeModuleDefs" DependsOnTargets="MakeDestDir">
<PropertyGroup>
<DestFile>$(DestDir)moduledefs.h</DestFile>
<TmpFile>$(DestFile).tmp</TmpFile>
</PropertyGroup>
<ItemGroup>
<PyUserModuleFiles Include="@(ClCompile)">
<Path>$([System.String]::new('%(FullPath)').Replace('$(PyBaseDir)', ''))</Path>
</PyUserModuleFiles>
</ItemGroup>
<Exec Command="$(PyPython) $(PySrcDir)makemoduledefs.py --vpath=&quot;., $(PyBaseDir), $(PyUserCModules)&quot; @(PyUserModuleFiles->'%(Path)', ' ') > $(TmpFile)"/>
<MSBuild Projects="$(MSBuildThisFileFullPath)" Targets="CopyFileIfDifferent" Properties="SourceFile=$(TmpFile);DestFile=$(DestFile)"/>
</Target>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<Target Name="MakeQstrData" DependsOnTargets="MakeQstrDefs" Inputs="$(QstrDefsCollected);$(PyQstrDefs);$(QstrDefs)" Outputs="$(QstrGen)">
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
<PropertyGroup>
windows/msvc: Rewrite qstr auto-generation. Builds have been broken since reworking autogeneration in c618f91 and related, this gets fixed here by applying similar qstr generation logic for the msvc builds: c files are only preprocessed when changed (or not yet preprocessed) and the concatenated output is fed into makeqstrdefs.py. To speed up this process, the concatenated output is already filtered to contain only lines which makeqstrdefs really needs: this makes the qstr generation stage about twice as fast (checked on different machines).
2016-04-23 12:55:14 -04:00
<TmpFile>$(QstrGen).tmp</TmpFile>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
</PropertyGroup>
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
<Exec Command="$(PyClTool) /nologo /I@(PyIncDirs, ' /I') /D@(PreProcDefs, ' /D') /E $(PyQstrDefs) $(QstrDefs) > $(DestDir)qstrdefs.preprocessed.h"/>
<Exec Command="$(PyPython) $(PySrcDir)makeqstrdata.py $(DestDir)qstrdefs.preprocessed.h $(QstrDefsCollected) > $(TmpFile)"/>
windows/msvc: Implement automatic qstr generation using makeqstrdefs. Note this still needs some work: currently all source files are always preprocessed no matter which one actually changed, moreover that happens file by file without any parallellism so builds are painstakingly slow.
2016-03-15 05:22:34 -04:00
<MSBuild Projects="$(MSBuildThisFileFullPath)" Targets="CopyFileIfDifferent" Properties="SourceFile=$(TmpFile);DestFile=$(QstrGen)"/>
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>
py: Replace py-version.sh with makeversionhdr.py, written in Python. Also rename py-version.h to mpversion.h for consistency with mpconfig.h.
2015-04-22 12:38:05 -04:00
<Target Name="MakeVersionHdr" DependsOnTargets="MakeDestDir">
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>
py: Replace py-version.sh with makeversionhdr.py, written in Python. Also rename py-version.h to mpversion.h for consistency with mpconfig.h.
2015-04-22 12:38:05 -04:00
<DestFile>$(DestDir)mpversion.h</DestFile>
msvc: Use single build target for dealing with generated files Remove some duplication in the code for generating qstrdefs.generated.h and py-version.h
2015-01-02 10:31:49 -05:00
<TmpFile>$(DestFile).tmp</TmpFile>
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>
windows: Allow specifying the python executable to use for msvc builds This defaults to 'python' but can be now overridden if needed
2015-11-07 14:00:26 -05:00
<Exec Command="$(PyPython) $(PySrcDir)makeversionhdr.py $(TmpFile)"/>
msvc: Use single build target for dealing with generated files Remove some duplication in the code for generating qstrdefs.generated.h and py-version.h
2015-01-02 10:31:49 -05:00
<MSBuild Projects="$(MSBuildThisFileFullPath)" Targets="CopyFileIfDifferent" Properties="SourceFile=$(TmpFile);DestFile=$(DestFile)"/>
</Target>
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="FreezeModules" Condition="'$(FrozenManifest)' != ''" DependsOnTargets="MakeQstrData" Inputs="$(FrozenManifest)" Outputs="$(PyBuildDir)frozen_content.c">
<ItemGroup>
<ClCompile Include="$(PyBuildDir)frozen_content.c"/>
<ClCompile>
<PreprocessorDefinitions>MICROPY_MODULE_FROZEN_MPY=1;MICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool;%(PreprocessorDefinitions)</PreprocessorDefinitions>
</ClCompile>
</ItemGroup>
all: Remove MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE. This commit removes all parts of code associated with the existing MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE optimisation option, including the -mcache-lookup-bc option to mpy-cross. This feature originally provided a significant performance boost for Unix, but wasn't able to be enabled for MCU targets (due to frozen bytecode), and added significant extra complexity to generating and distributing .mpy files. The equivalent performance gain is now provided by the combination of MICROPY_OPT_LOAD_ATTR_FAST_PATH and MICROPY_OPT_MAP_LOOKUP_CACHE (which has been enabled on the unix port in the previous commit). It's hard to provide precise performance numbers, but tests have been run on a wide variety of architectures (x86-64, ARM Cortex, Aarch64, RISC-V, xtensa) and they all generally agree on the qualitative improvements seen by the combination of MICROPY_OPT_LOAD_ATTR_FAST_PATH and MICROPY_OPT_MAP_LOOKUP_CACHE. For example, on a "quiet" Linux x64 environment (i3-5010U @ 2.10GHz) the change from CACHE_MAP_LOOKUP_IN_BYTECODE, to LOAD_ATTR_FAST_PATH combined with MAP_LOOKUP_CACHE is: diff of scores (higher is better) N=2000 M=2000 bccache -> attrmapcache diff diff% (error%) bm_chaos.py 13742.56 -> 13905.67 : +163.11 = +1.187% (+/-3.75%) bm_fannkuch.py 60.13 -> 61.34 : +1.21 = +2.012% (+/-2.11%) bm_fft.py 113083.20 -> 114793.68 : +1710.48 = +1.513% (+/-1.57%) bm_float.py 256552.80 -> 243908.29 : -12644.51 = -4.929% (+/-1.90%) bm_hexiom.py 521.93 -> 625.41 : +103.48 = +19.826% (+/-0.40%) bm_nqueens.py 197544.25 -> 217713.12 : +20168.87 = +10.210% (+/-3.01%) bm_pidigits.py 8072.98 -> 8198.75 : +125.77 = +1.558% (+/-3.22%) misc_aes.py 17283.45 -> 16480.52 : -802.93 = -4.646% (+/-0.82%) misc_mandel.py 99083.99 -> 128939.84 : +29855.85 = +30.132% (+/-5.88%) misc_pystone.py 83860.10 -> 82592.56 : -1267.54 = -1.511% (+/-2.27%) misc_raytrace.py 21490.40 -> 22227.23 : +736.83 = +3.429% (+/-1.88%) This shows that the new optimisations are at least as good as the existing inline-bytecode-caching, and are sometimes much better (because the new ones apply caching to a wider variety of map lookups). The new optimisations can also benefit code generated by the native emitter, because they apply to the runtime rather than the generated code. The improvement for the native emitter when LOAD_ATTR_FAST_PATH and MAP_LOOKUP_CACHE are enabled is (same Linux environment as above): diff of scores (higher is better) N=2000 M=2000 native -> nat-attrmapcache diff diff% (error%) bm_chaos.py 14130.62 -> 15464.68 : +1334.06 = +9.441% (+/-7.11%) bm_fannkuch.py 74.96 -> 76.16 : +1.20 = +1.601% (+/-1.80%) bm_fft.py 166682.99 -> 168221.86 : +1538.87 = +0.923% (+/-4.20%) bm_float.py 233415.23 -> 265524.90 : +32109.67 = +13.756% (+/-2.57%) bm_hexiom.py 628.59 -> 734.17 : +105.58 = +16.796% (+/-1.39%) bm_nqueens.py 225418.44 -> 232926.45 : +7508.01 = +3.331% (+/-3.10%) bm_pidigits.py 6322.00 -> 6379.52 : +57.52 = +0.910% (+/-5.62%) misc_aes.py 20670.10 -> 27223.18 : +6553.08 = +31.703% (+/-1.56%) misc_mandel.py 138221.11 -> 152014.01 : +13792.90 = +9.979% (+/-2.46%) misc_pystone.py 85032.14 -> 105681.44 : +20649.30 = +24.284% (+/-2.25%) misc_raytrace.py 19800.01 -> 23350.73 : +3550.72 = +17.933% (+/-2.79%) In summary, compared to MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE, the new MICROPY_OPT_LOAD_ATTR_FAST_PATH and MICROPY_OPT_MAP_LOOKUP_CACHE options: - are simpler; - take less code size; - are faster (generally); - work with code generated by the native emitter; - can be used on embedded targets with a small and constant RAM overhead; - allow the same .mpy bytecode to run on all targets. See #7680 for further discussion. And see also #7653 for a discussion about simplifying mpy-cross options. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2021-09-05 22:28:06 -04:00
<Exec Command="$(PyPython) $(PyBaseDir)tools\makemanifest.py -v MPY_DIR=$(PyBaseDir) -v MPY_LIB_DIR=$(PyBaseDir)../micropython-lib -v PORT_DIR=$(PyWinDir) -o $(PyBuildDir)frozen_content.c -b $(PyBuildDir) $(FrozenManifest)"/>
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
<WriteLinesToFile File="$(TLogLocation)frozen.read.1.tlog" Lines="$(FrozenManifest)" Overwrite="True"/>
</Target>
msvc: Remove directory with generated files when cleaning. This assures after cleaning all build artefacts (qstr related files, generated version header) have been removed.
2017-03-22 05:54:40 -04:00
<Target Name="RemoveGeneratedFiles" AfterTargets="Clean">
<RemoveDir Directories="$(DestDir)"/>
</Target>
msvc: Use single build target for dealing with generated files Remove some duplication in the code for generating qstrdefs.generated.h and py-version.h
2015-01-02 10:31:49 -05:00
<!--Copies SourceFile to DestFile only if SourceFile's content differs from DestFile's.
We use this to 'touch' the generated files only when they are really newer
so a build is only triggered if the generated content actually changed,
and not just because the file date changed since the last build-->
<Target Name="CopyFileIfDifferent">
<Exec Command="fc /B $(SourceFile) $(DestFile) > NUL 2>&amp;1" IgnoreExitCode="true">
msvc: Only update generated headers when there are changes This fixes generating the headers casuing complete rebuilds, even when the headere's content didn't really change.
2014-05-28 10:03:38 -04:00
<Output TaskParameter="ExitCode" PropertyName="FilesDiffer" />
</Exec>
msvc: Use single build target for dealing with generated files Remove some duplication in the code for generating qstrdefs.generated.h and py-version.h
2015-01-02 10:31:49 -05:00
<Copy SourceFiles="$(SourceFile)" DestinationFiles="$(DestFile)" Condition="'$(FilesDiffer)'!='0'"/>
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>
</Project>