Update base for Update on "[cmake] Fix CI job"

Summary: Fix an issue caused by #1036

Test Plan:

Reviewers:

Subscribers:

Tasks:

Tags:

[ghstack-poisoned]

Author: larryliu0820

CONTRIBUTING.md

@@ -54,8 +54,7 @@ modifications to the Google C++ style guide.
 
 ### C++ Portability Guidelines
 
-See also
-[Portable Programming](https://github.com/pytorch/executorch/blob/main/docs/website/docs/contributors/portable_programming.md)
+See also [Portable C++ Programming](/docs/source/portable-cpp-programming.md)
 for detailed advice.
 
 #### C++ language version
@@ -110,10 +109,9 @@ must work with threading**
   `ArrayRef<T>`, or code that handles multiple `ScalarType` types), but for the
   most part avoid them if possible.
 
-## For Delegate Authors
+## For Backend Delegate Authors
 
-* Use [this](/docs/website/docs/contributors/delegates.md)
-guide when integrating your delegate with ExecuTorch.
-
-* Refer to [this](/docs/website/docs/contributors/delegates_and_dependencies.md)
-set of guidelines when including a 3p depenency for your delegate.
+- Use [this](/docs/source/backend-delegates-integration.md) guide when
+  integrating your delegate with ExecuTorch.
+- Refer to [this](/docs/source/backend-delegates-dependencies.md) set of
+  guidelines when including a third-party depenency for your delegate.

docs/website/docs/contributors/delegates_and_dependencies.md renamed to docs/source/backend-delegates-dependencies.md

@@ -1,12 +1,12 @@
-# Dependencies Management for Backend Delegatation
+# Third-Party Dependency Management for Backend Delegates
 
 Disclaimer: We are planning to restructure the repository around delegates.
 With that some of these guidelines will change in the future.
 
 A delegate may depend on external, third-party libraries to efficiently
-implement ahead-of-time (AoT) `partition()` or `preprocess()` functions, and/or
-to implement runtime functions such as `init()` or `execute()`, or run tests in
-a specific manner. This guide aims to classify different types of third-party
+implement ahead-of-time (AOT) `partition()` or `preprocess()` functions, and/or
+to implement runtime functions such as `init()` or `execute()`, or to run tests
+in a specific manner. This guide aims to classify different types of third-party
 dependencies a delegate might depend on, and provide a high level guidance on
 how to include them.
 
@@ -17,16 +17,15 @@ This includes dependencies used by the delegate's `partitioner()` and
 will be used at later at runtime.
 
 Depending on how the `preprocess()` function is implemented this can be either
-Python or C++ dependency. This guide will talk about only Python AoT dependencies.
+Python or C++ dependency. This guide will talk about only Python AOT dependencies.
 
 **Guidelines:**
 
 * If ExecuTorch already includes a dependency you require, prefer
   to use that if possible.
-* Since the dependency is only used by the files inside the
-  `executorch/backends/<delegate_name>/` - it should introduced in
-  a way that it is needed only by the code inside the backend delegate
-  directory.
+* If the dependency is only needed by the files inside the
+  `executorch/backends/<delegate_name>/` directory, it should be introduced in a
+  way such that it is used only by the code under that directory.
 * The dependency should not be installed by default when installing
   the ExecuTorch Python package.
 
@@ -41,51 +40,49 @@ subgraph for the delegate.
 
 **Guidelines:**
 
-At a high level, only pay for what you use should be the desired approach
+At a high level, "only pay for what you use" should be the desired approach
 for these third-party dependencies.
 
-* Similar to the AoT dependencies, the use of this should also be restricted to
+* Similar to the AOT dependencies, the use of this should also be restricted to
   only the delegate runtime source files.
 * If a delegate has a dependency which is already part of
   `executorch/third-party` then try to use that if possible. This
   helps with reducing the binary size when the delegate is enabled.
-* Rest of the ExecuTorch code, outside of the delegate, should not depend on
+* The rest of the ExecuTorch code, outside of the delegate, should not depend on
   this. And it should should build and run correctly without this dependency
   when the delegate is disabled at build time.
 
 More details in the section [below](#runtime-dependencies).
 
 ## Testing-Only Dependencies
 
-Some libraries, or tools are only used for executing the delegate tests. These
+Some libraries or tools are only used for executing the delegate tests. These
 can either be a Python dependency or a C++ dependency depending on the type of
 the test.
 
 **Guidelines:**
 
-* For a Python dependency, it should not be installed by default when
+* For a Python test dependency, it should not be installed by default when
   installing the ExecuTorch Python package.
-* If for C++ tests, it should not be part of the
-  ExecuTorch runtime even when the delegate is built/enabled.
+* For a C++ test dependency, it should not be part of the ExecuTorch runtime
+  even when the delegate is built/enabled.
 
-## Other considerations
+## Other Considerations
 
 ### Versioning
 
-Explicit and specific is preferred. For example a pypi version (or a criteria) or
+Explicit and specific is preferred. For example a PyPI version (or range) or
 a git tag/release.
 
-### End user vs. Developer experience
-
-* More details TBD
-
 <!---
+### End-User vs. Developer Experience
+
 TODO
 Need to add more about developer experiences, users selecting which delegates
-to enable/install for both AoT and Runtime
+to enable/install for both AOT and Runtime
 --->
 
-### Documenting the dependency
+### Documenting Dependencies
 At a minimum, some documentation under `executorch/backends/<delegate_name>/`
 should be provided when introducing a new dependency which includes,
 
@@ -106,34 +103,32 @@ dependencies under `executorch/backends/<delegate_name>/requirements.txt` to be
 supplied to pip at installation time. The goal is to decouple them from the core
 ExecuTorch dependencies.
 
-Version conflict should be avoided by trying to use the already included
-dependency by ExecuTorch or by some other backend if possible. Otherwise
-try some other
+Version conflicts should be avoided by trying to use the dependency already
+included by ExecuTorch or by some other backend if possible. Otherwise try some
+other
 [recommended](https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts)
 ways to mitigate version conflicts.
 
 #### Local Python Packages
 If it is a git repository, it should be added as a git submodule.
 
-* More details TBD
-
-<!-- Something like
+<!--
+TODO: Add more details. Something like
 https://packaging.python.org/en/latest/tutorials/installing-packages/#installing-from-vcs,
-but the URLs can't be in the requirements.txt, so not recommending this for now. -->
+but the URLs can't be in the requirements.txt, so not recommending this for now.
+-->
 
 ## C++ Dependencies
 
 The recommended approach is to include a git submodule for a given C++
-dependency in the `executorch/backends/<delegate_name>/third-party`.
-
-### buck2/CMake support
-At a minimum CMake support is required. Adding buck2 support should make
-the delegate available to more ExecuTorch users.
+dependency in the `executorch/backends/<delegate_name>/third-party` directory.
 
-* More details TBD
+### buck2/CMake Support
+At a minimum CMake support is required. Adding buck2 support is optional, but
+will make the delegate available to more ExecuTorch users.
 
 <!---
-TODO
-Complying with ET runtime build configurations. Standard switches for library
-linking (i.e. static, PIC), optimization flags pass through, etc.
+TODO: Add more details about: complying with ET runtime build configurations;
+standard switches for library linking (i.e. static, PIC), optimization flags
+pass through, etc.
 --->

docs/website/docs/contributors/delegates.md renamed to docs/source/backend-delegates-integration.md

@@ -1,4 +1,4 @@
-# How to integrate a Backend Delegate with ExecuTorch?
+# Integrating a Backend Delegate into ExecuTorch
 
 Disclaimer: We are planning to restructure the repository around delegates.
 With that some of these guidelines will change in the future.
@@ -8,17 +8,17 @@ This is a high level guideline when integrating a backend delegate with ExecuTor
 ## Directory Structure
 
 Delegate files should be under this directory:
-`executorch/backends/<delegate_name>/`. Delegate name should be unique.
+`executorch/backends/<delegate_name>/`. The delegate name should be unique.
 
-## Python files
+## Python Source Files
 
-Delegate Python files such as one implementing `preprocess()` or `partition()`
-functions for ExecuTorch AoT flow, excluding any external third-party
+Delegate Python files such as those implementing `preprocess()` or `partition()`
+functions for ExecuTorch AOT flow, excluding any external third-party
 dependencies and their files, should be installed and available with
 the top level ExecuTorch package. For third-party dependencies, please refer to
-[this](./delegates_and_dependencies.md).
+[this](./backend-delegates-dependencies.md).
 
-## C++ sources
+## C++ Source Files
 
 At a minimum, a delegate must provide CMake support for building its C++
 sources.
@@ -28,35 +28,34 @@ top level `CMakeLists.txt` file using `add_subdirectory` CMake command, and
 should be built conditionally with an ExecuTorch build flag like
 `EXECUTORCH_BUILD_<DELEGATE_NAME>`, see `EXECUTORCH_BUILD_XNNPACK` for example.
 For third-party dependencies, please refer to
-[this](./delegates_and_dependencies.md).
+[this](./backend-delegates-dependencies.md).
 
-Adding buck2 support should make the delegate available to more
-ExecuTorch users.
 
-* More details TBD
+Adding buck2 support is optional, but will make the delegate available to more
+ExecuTorch users.
 
 <!---
-TODO
-Need to insert a CMake layer in `executorch/backends` to provide some
-uniform abstraction across delegates.
+TODO: Add more details. Need to insert a CMake layer in `executorch/backends` to
+provide some uniform abstraction across delegates.
 --->
 
-
 ## Tests
 
-Tests should be added under `executorch/backends/<delegate_name>/test`.
-Tests can be either python or C++ tests, for adding more complex e2e please reach out to us.
-
-* Python unit-tests, which are simple python tests to test AoT logic such as
-`partitioner()`, AoT export flow i.e., `nn.Module` to generating the `.pte` file.
+Tests should be added under `executorch/backends/<delegate_name>/test`. Tests
+can be either python or C++ tests. For adding more complex end-to-end (e2e)
+tests, please reach out to us.
 
-* Runtime C++ tests, using gtest, can be implemented to test delegate `init()`
-or `execute()` logic.
+Common test types:
+* Simple python unit tests that test AOT logic such as `partitioner()` or AOT
+  export flow (generating a `.pte` file from an `nn.Module`)
+* Runtime C++ tests, using gtest, that test delegate `init()` or `execute()`
+  runtime logic.
 
 ## Documentation
 
 A delegate must contain a `executorch/backends/<delegate_name>/README.md`
-explaining the basics of the delegate, directory structure, features, and known-issues if any.
+explaining the basics of the delegate, directory structure, features, and known
+issues if any.
 
-Any extra setup step(s) beyond the ones listed above, should be documented in
+Any extra setup steps beyond the ones listed above should be documented in
 `executorch/backends/<delegate_name>/setup.md`