[edk2-wiki][PATCH v2 3/4] Add top-level build instructions file

["Michael Kubacki" <mikuback@linux.microsoft.com>]

From: Michael Kubacki <michael.kubacki@microsoft.com>

Adds a file that describes various build approaches in edk2 at a
high-level and points to the documents with specific instructions
for each approach.

This is a starting point for this file and it will likely be
expanded upon in the future.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
---
 Build-Instructions.md | 35 ++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/Build-Instructions.md b/Build-Instructions.md
new file mode 100644
index 000000000000..2b6d19725c7d
--- /dev/null
+++ b/Build-Instructions.md
@@ -0,0 +1,35 @@
+# EDK II Build Instructions
+
+Over the life of the project, EDK II has evolved it's build process. A common theme has been reducing the number of
+manual steps involved and easing environment setup and configuration so developers can more quickly get started writing
+firmware code.
+
+There's currently three high-level approaches to build (listed in recommended order):
+
+1. [Containers](How-to-Develop-With-Containers.md)
+2. [Stuart](How-to-Build-With-Stuart.md)
+3. [build](Getting-Started-with-EDK-II.mediawiki)
+
+## Build Option Comparison
+
+Containers have seen widespread adoption in software development. The capability to deploy well-defined, ready-to-go
+images, results in unmatched performance, portability, and consistency of build environments. By extension, TianoCore
+leverages containers for both server-side builds (e.g. for pull requests and continuous integration) and for local
+developer builds. The TianoCore project maintains containers in
+[tianocore/containers](https://github.com/tianocore/containers).
+
+If you just want to get started quickly and be able to receive the best support possible (since issues in containers
+are easy to reproduce, fix, and deploy), then start with the container instructions.
+
+Prior to containers, building involved a lot of manual steps. Downloading compilers, various dependencies, running
+the right commands in the right order, and so on. A lot of that work was reduced and moved into a tool that
+orchestrates a lot of the underlying steps needed to simply set up a build environment and start building code. That
+tool is called "Stuart". So if you would like a local build environment without using containers, it is recommended
+to use Stuart. Containers use Stuart and the CI system uses Stuart and many CI checks are performed by Stuart to allow
+pull requests to be submitted. So running CI locally with Stuart will put you in a great position to have code ready
+for contribution to the project.
+
+At the core of the build is an application called `build`. Ultimately, containers and Stuart will eventually call
+`build` to actually build the code and prior to the introduction of those two approaches, `build` was the primary
+build path. So, you can still call `build` directly. This will result in more manual steps and a lack of the feature
+set brought by the other two options but you can produce a working firmware image (in most cases) with `build`.
-- 
2.28.0.windows.1