2019-05-03 00:29:04 +02:00
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
|
|
|
|
<ItemGroup>
|
|
|
|
<Natvis Include="$(SolutionDir)tools\ConsoleTypes.natvis" />
|
|
|
|
</ItemGroup>
|
2019-11-05 23:29:11 +01:00
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
|
2019-11-05 23:29:11 +01:00
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
<ItemDefinitionGroup>
|
2019-11-05 23:29:11 +01:00
|
|
|
<!-- Definition the program database type has to come after Microsoft.Cpp.props or it will be
|
|
|
|
rewritten to /ZI (edit-and-continue) type every time. -->
|
2019-05-03 00:29:04 +02:00
|
|
|
<ClCompile>
|
|
|
|
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
|
|
|
|
</ClCompile>
|
2019-11-05 23:29:11 +01:00
|
|
|
<Link>
|
2019-12-12 14:44:01 +01:00
|
|
|
<AdditionalDependencies>onecoreuap_apiset.lib;d3dcompiler.lib;dwmapi.lib;uxtheme.lib;shlwapi.lib;ntdll.lib;%(AdditionalDependencies)</AdditionalDependencies>
|
2019-11-05 23:29:11 +01:00
|
|
|
</Link>
|
|
|
|
</ItemDefinitionGroup>
|
|
|
|
|
|
|
|
<!-- DLLs Only -->
|
|
|
|
<ItemDefinitionGroup Condition="'$(ConfigurationType)' == 'DynamicLibrary'">
|
|
|
|
<ClCompile>
|
|
|
|
<PreprocessorDefinitions>_USRDLL;%(PreprocessorDefinitions)</PreprocessorDefinitions>
|
|
|
|
</ClCompile>
|
|
|
|
</ItemDefinitionGroup>
|
|
|
|
|
|
|
|
<!-- Static Libs Only -->
|
|
|
|
<ItemDefinitionGroup Condition="'$(ConfigurationType)' == 'StaticLibrary'">
|
|
|
|
<ClCompile>
|
|
|
|
<PreprocessorDefinitions>_LIB;%(PreprocessorDefinitions)</PreprocessorDefinitions>
|
|
|
|
</ClCompile>
|
2019-05-03 00:29:04 +02:00
|
|
|
</ItemDefinitionGroup>
|
2019-11-05 23:29:11 +01:00
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
|
2019-11-05 23:29:11 +01:00
|
|
|
|
2019-05-24 23:48:10 +02:00
|
|
|
<!-- Exclude our dependencies from static analysis. CAExcludePath can only be
|
|
|
|
set after we've imported Microsoft.Cpp.targets -->
|
|
|
|
<PropertyGroup>
|
|
|
|
<CAExcludePath>$(SolutionDir)\dep\;$(CAExcludePath)</CAExcludePath>
|
|
|
|
</PropertyGroup>
|
2019-11-05 23:29:11 +01:00
|
|
|
|
Fix our parallel (and repeating) builds (#3412)
The WAP packaging project in VS <= 16.3.7 produces a couple global
properties as part of its normal operation that cause MSBuild to flag
our projects as out-of-date and requiring a rebuild. By forcing those
properties to match the WAP values, we can get consistent builds.
One of those properties, however, is "GenerateAppxPackageOnBuild", and
WAP sets it to *false*. When we set that, of course, we don't get an
MSIX out of our build pipeline. Therefore, we have to break our build
into two phases -- build, then package.
This required us to change our approach to PCH deletion. A project
without a PCH is *also* considered out-of-date. Now, we keep all PCH
files but truncate them to 0 bytes.
TerminalApp, however, is re-linked during packaging because the Xaml
compiler emits a new generated C++ file on every build. We have to keep
those PCHs around.
* Remove WpfTerminalControl AnyCPU from Arch-specific builds
This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level.
This also cleans up some new projects that were added and build for "Any
CPU".
2019-11-01 22:38:13 +01:00
|
|
|
<Target Name="_ComputePrecompToCleanUp">
|
2019-08-06 13:51:50 +02:00
|
|
|
<ItemGroup>
|
Fix our parallel (and repeating) builds (#3412)
The WAP packaging project in VS <= 16.3.7 produces a couple global
properties as part of its normal operation that cause MSBuild to flag
our projects as out-of-date and requiring a rebuild. By forcing those
properties to match the WAP values, we can get consistent builds.
One of those properties, however, is "GenerateAppxPackageOnBuild", and
WAP sets it to *false*. When we set that, of course, we don't get an
MSIX out of our build pipeline. Therefore, we have to break our build
into two phases -- build, then package.
This required us to change our approach to PCH deletion. A project
without a PCH is *also* considered out-of-date. Now, we keep all PCH
files but truncate them to 0 bytes.
TerminalApp, however, is re-linked during packaging because the Xaml
compiler emits a new generated C++ file on every build. We have to keep
those PCHs around.
* Remove WpfTerminalControl AnyCPU from Arch-specific builds
This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level.
This also cleans up some new projects that were added and build for "Any
CPU".
2019-11-01 22:38:13 +01:00
|
|
|
<PCHFileToClean Include="$(IntDir)\**\*.pch" />
|
|
|
|
<PCHFileToClean Include="$(IntDir)\**\precomp.obj" />
|
|
|
|
<_PCHFileToCleanWithTimestamp Include="@(PCHFileToClean)" Condition="'%(Identity)' != ''">
|
|
|
|
<LastWriteTime>$([System.IO.File]::GetLastWriteTime('%(Identity)'))</LastWriteTime>
|
|
|
|
</_PCHFileToCleanWithTimestamp>
|
2019-08-06 13:51:50 +02:00
|
|
|
</ItemGroup>
|
Fix our parallel (and repeating) builds (#3412)
The WAP packaging project in VS <= 16.3.7 produces a couple global
properties as part of its normal operation that cause MSBuild to flag
our projects as out-of-date and requiring a rebuild. By forcing those
properties to match the WAP values, we can get consistent builds.
One of those properties, however, is "GenerateAppxPackageOnBuild", and
WAP sets it to *false*. When we set that, of course, we don't get an
MSIX out of our build pipeline. Therefore, we have to break our build
into two phases -- build, then package.
This required us to change our approach to PCH deletion. A project
without a PCH is *also* considered out-of-date. Now, we keep all PCH
files but truncate them to 0 bytes.
TerminalApp, however, is re-linked during packaging because the Xaml
compiler emits a new generated C++ file on every build. We have to keep
those PCHs around.
* Remove WpfTerminalControl AnyCPU from Arch-specific builds
This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level.
This also cleans up some new projects that were added and build for "Any
CPU".
2019-11-01 22:38:13 +01:00
|
|
|
</Target>
|
|
|
|
<!-- Instead of outright deleting the PCHs, we want to trick the "project freshness detector" by
|
|
|
|
emitting empty files that look suspiciously like the PCHs it's expecting.
|
|
|
|
It's of utmost importance that their timestamps match up. -->
|
|
|
|
<Target Name="CleanUpPrecompForSmallCIAgents"
|
|
|
|
DependsOnTargets="_ComputePrecompToCleanUp"
|
|
|
|
AfterTargets="AfterBuild"
|
2020-10-28 21:49:13 +01:00
|
|
|
Condition="'$(OpenConsoleCleanPCH)' == 'true' and '$(AGENT_ID)' != '' and !$(ProjectName.Contains('TerminalApp'))">
|
Fix our parallel (and repeating) builds (#3412)
The WAP packaging project in VS <= 16.3.7 produces a couple global
properties as part of its normal operation that cause MSBuild to flag
our projects as out-of-date and requiring a rebuild. By forcing those
properties to match the WAP values, we can get consistent builds.
One of those properties, however, is "GenerateAppxPackageOnBuild", and
WAP sets it to *false*. When we set that, of course, we don't get an
MSIX out of our build pipeline. Therefore, we have to break our build
into two phases -- build, then package.
This required us to change our approach to PCH deletion. A project
without a PCH is *also* considered out-of-date. Now, we keep all PCH
files but truncate them to 0 bytes.
TerminalApp, however, is re-linked during packaging because the Xaml
compiler emits a new generated C++ file on every build. We have to keep
those PCHs around.
* Remove WpfTerminalControl AnyCPU from Arch-specific builds
This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level.
This also cleans up some new projects that were added and build for "Any
CPU".
2019-11-01 22:38:13 +01:00
|
|
|
<!-- We just need to keep *TerminalApp*'s PCHs because they get rebuilt more often. -->
|
|
|
|
<Delete Files="@(_PCHFileToCleanWithTimestamp)"/>
|
|
|
|
<Touch Files="@(_PCHFileToCleanWithTimestamp)" Time="%(LastWriteTime)" AlwaysCreate="true" />
|
|
|
|
<Message Text="PCH and Precomp object @(_PCHFileToCleanWithTimestamp) has been deleted for $(ProjectName)." />
|
2019-08-06 13:51:50 +02:00
|
|
|
</Target>
|
2019-05-03 00:29:04 +02:00
|
|
|
</Project>
|