mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
micropython/ports/windows/msvc/genhdr.targets

134 lines
7.0 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 11:18:27 +01:00
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="GenerateHeaders">
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 08:42:12 +00: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 10:49:23 +00: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 17:55:14 +01: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-18 03:58:44 +00: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 11:18:27 +01: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 10:49:23 +00: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 17:38:05 +01: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 05:09:13 +01: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 17:55:14 +01: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 09:22:34 +00:00
<QstrDefsCollected>$(DestDir)qstrdefscollected.h</QstrDefsCollected>
<QstrGen>$(DestDir)qstrdefs.generated.h</QstrGen>
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 19:00:26 +00: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 12:29:03 +01:00
<CLToolExe Condition="'$(CLToolExe)' == ''">cl.exe</CLToolExe>
<PyClTool>$([System.IO.Path]::Combine(`$(CLToolPath)`, `$(CLToolExe)`))</PyClTool>
Windows MSVC port Extend the windows port so it compiles with the toolchain from Visual Studio 2013
2014-05-05 11:18:27 +01:00
</PropertyGroup>
<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 17:55:14 +01: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 12:16:12 +01: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 17:55:14 +01: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 12:16:12 +01: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 09:22:34 +00: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 16:14:45 +01:00
<PreProcDefs Include="%(ClCompile.PreProcessorDefinitions);NO_QSTR"/>
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 17:55:14 +01:00
<PyQstrSourceFiles Include="@(ClCompile)">
<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 09:22:34 +00: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 17:55:14 +01: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 09:22:34 +00: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 12:16:12 +01: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 09:22:34 +00: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 12:16:12 +01: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 09:22:34 +00: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 12:16:12 +01:00
<PropertyGroup>
<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 09:50:58 +01: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 12:16:12 +01:00
</PropertyGroup>
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 09:22:34 +00: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 17:55:14 +01:00
<MakeDir Directories="@(PyQstrSourceFiles->'%(OutDir)')"/>
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 12:29:03 +01:00
<Exec Command="$(PyClTool) /nologo /I@(PyIncDirs, ' /I') /D@(PreProcDefs, ' /D') /Fi%(PyQstrSourceFiles.OutFile) /P %(PyQstrSourceFiles.Identity)"
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 12:16:12 +01:00
Condition="'%(PyQstrSourceFiles.Changed)' == 'True' Or '$(ForceQstrRebuild)' == 'True'"/>
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 17:55:14 +01: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 09:50:58 +01:00
Condition="'$(RunPreProcConcat)' == 'True' Or '$(ForceQstrRebuild)' == 'True'"/>
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 17:55:14 +01:00
<Exec Command="$(PyPython) $(PySrcDir)makeqstrdefs.py split $(DestDir)qstr.i.last $(DestDir)qstr $(QstrDefsCollected)"/>
<Exec Command="$(PyPython) $(PySrcDir)makeqstrdefs.py cat $(DestDir)qstr.i.last $(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 09:22:34 +00: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-18 03:58:44 +00: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 17:55:14 +01: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 09:22:34 +00: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 17:55:14 +01: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 09:22:34 +00:00
</PropertyGroup>
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 12:29:03 +01:00
<Exec Command="$(PyClTool) /nologo /I@(PyIncDirs, ' /I') /D@(PreProcDefs, ' /D') /E $(PyQstrDefs) $(QstrDefs) > $(DestDir)qstrdefspreprocessed.h"/>
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 17:55:14 +01:00
<Exec Command="$(PyPython) $(PySrcDir)makeqstrdata.py $(DestDir)qstrdefspreprocessed.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 09:22:34 +00: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 11:18:27 +01: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 17:38:05 +01: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 11:18:27 +01: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 17:38:05 +01: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 15:31:49 +00: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 11:18:27 +01: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 19:00:26 +00: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 15:31:49 +00:00
<MSBuild Projects="$(MSBuildThisFileFullPath)" Targets="CopyFileIfDifferent" Properties="SourceFile=$(TmpFile);DestFile=$(DestFile)"/>
</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 09:54:40 +00: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 15:31:49 +00: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 15:03:38 +01: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 15:31:49 +00: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 11:18:27 +01:00
</Target>
</Project>