31a39b3b12
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_.
85 lines
3.8 KiB
XML
85 lines
3.8 KiB
XML
<?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>
|
|
|
|
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
|
|
|
|
<ItemDefinitionGroup>
|
|
<!-- 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. -->
|
|
<ClCompile>
|
|
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
|
|
</ClCompile>
|
|
<Link>
|
|
<AdditionalDependencies>onecoreuap_apiset.lib;d3dcompiler.lib;dwmapi.lib;uxtheme.lib;shlwapi.lib;ntdll.lib;%(AdditionalDependencies)</AdditionalDependencies>
|
|
</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>
|
|
</ItemDefinitionGroup>
|
|
|
|
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
|
|
|
|
<!-- 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" />
|
|
|
|
<!-- 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>
|
|
|
|
<Target Name="_ComputePrecompToCleanUp">
|
|
<ItemGroup>
|
|
<PCHFileToClean Include="$(IntDir)\**\*.pch" />
|
|
<PCHFileToClean Include="$(IntDir)\**\precomp.obj" />
|
|
<_PCHFileToCleanWithTimestamp Include="@(PCHFileToClean)" Condition="'%(Identity)' != ''">
|
|
<LastWriteTime>$([System.IO.File]::GetLastWriteTime('%(Identity)'))</LastWriteTime>
|
|
</_PCHFileToCleanWithTimestamp>
|
|
</ItemGroup>
|
|
</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"
|
|
Condition="'$(OpenConsoleCleanPCH)' == 'true' and '$(AGENT_ID)' != '' and !$(ProjectName.Contains('TerminalApp'))">
|
|
<!-- 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)." />
|
|
</Target>
|
|
|
|
<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>
|
|
</Project>
|