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
|
|
|
|
2021-05-13 23:12:30 +02:00
|
|
|
<!-- PGO -->
|
|
|
|
|
<Import Condition="'$(PgoTarget)' == 'true' And '$(PGOBuildMode)' == 'Optimize'" Project="$(SolutionDir)packages\$(PGODatabaseId).$(PGODatabaseVersion)\build\PGO.targets" />
|
|
|
|
|
<Import Condition="'$(PgoTarget)' == 'true' And '$(PGOBuildMode)' == 'Instrument'" Project="$(SolutionDir)\src\common.pgo.runtime.props" />
|
|
|
|
|
|
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>
|
Add support for branch- and branding-based feature flagging (#10361)
This pull request implements a "feature flagging" system that will let
us turn Terminal and conhost features on/off by branch, "release" status
or branding (Dev, Preview, etc.).
It's loosely modelled after the Windows OS concept of "Velocity," but
only insofar as it is driven by an XML document and there's a tool that
emits a header file for you to include.
It only supports toggling features at compile time, and the feature flag
evaluators are intended to be fully constant expressions.
Features are added to `src\features.xml` and marked with a "stage". For
now, the only stages available are `AlwaysDisabled` and `AlwaysEnabled`.
Features can be toggled to different states using branch and branding
tokens, as documented in the included feature flag docs.
For a given feature Feature_XYZ, we will emit two fixtures visible to
the compiler:
1. A preprocessor define `TIL_FEATURE_XYZ_ENABLED` (usable from MIDL,
C++ and C)
2. A feature class type `Feature_XYZ` with a static constexpr member
`IsEnabled()` (usable from C++, designed for `if constexpr()`).
Like Velocity, we rely on the compiler to eliminate dead code caused by
things that compile down to `if constexpr (false)`. :)
Michael suggested that we could use `WindowsInbox` as a branding to
determine when we were being built inside Windows to supplant our use of
the `__INSIDE_WINDOWS` preprocessor token. It was brilliant.
Design Decisions
----------------
* Emitting the header as part of an MSBuild project
* WHY: This allows the MSBuild engine to ensure that the build is
only run once, even in a parallel build situation.
* Only having one feature flag document for the entire project
* WHY: Ease.
* Forcibly including `TilFeatureStaging` with `/FI` for all CL compiler
invocations.
* WHY: If this is a project-wide feature system, we should make it as
easy as possible to use.
* Emitting preprocessor definitions instead of constexpr/consteval
* WHY: Removing entire functions/includes is impossible with `if
constexpr`.
* WHY: MIDL cannot use a `static constexpr bool`, but it can rely on
the C preprocessor to remove text.
* Using MSBuild to emit the text instead of PowerShell
* WHY: This allows us to leverage MSBuild's `WriteOnlyWhenDifferent`
task parameter to avoid changing the file's modification time when
it would have resulted in the same contents. This lets us use the
same FeatureStaging header across multiple builds and multiple
branches and brandings _assuming that they do not result in a
feature flag change_.
* The risk in using a force-include is always that it, for some
reason, determines that the entire project is out of date. We've
gone to great lengths to make sure that it only does so if the
features _actually materially changed_.
2021-06-11 01:09:52 +02:00
|
|
|
|
|
|
|
|
<PropertyGroup>
|
|
|
|
|
<BuildDependsOn>
|
|
|
|
|
OCCallFeatureFlagGenerator;
|
|
|
|
|
$(BuildDependsOn)
|
|
|
|
|
</BuildDependsOn>
|
|
|
|
|
</PropertyGroup>
|
|
|
|
|
|
|
|
|
|
<Target Name="OCCallFeatureFlagGenerator">
|
|
|
|
|
<MSBuild Projects="$(SolutionDir)\build\rules\GenerateFeatureFlags.proj" />
|
|
|
|
|
</Target>
|
|
|
|
|
|
|
|
|
|
<ItemDefinitionGroup>
|
|
|
|
|
<ClCompile>
|
|
|
|
|
<ForcedIncludeFiles>$(SolutionDir)\bin\$(Configuration)\inc\TilFeatureStaging.h;%(ForcedIncludeFiles)</ForcedIncludeFiles>
|
|
|
|
|
</ClCompile>
|
|
|
|
|
</ItemDefinitionGroup>
|
2019-05-03 00:29:04 +02:00
|
|
|
</Project>
|
