update sdk doc from mvp

docs/source/sdk-etdump.md

@@ -34,31 +34,11 @@ if (result.buf != nullptr && result.size > 0) {
   }
 ```
 
-4. ***Compile*** your binary with the `ET_EVENT_TRACER_ENABLED` pre-processor flag to enable events to be traced and logged into ETDump inside the ExecuTorch runtime.
-
-    i). ***Buck***
-
-    In Buck, users simply depend on the etdump target which is:
-    ```
-    //executorch/sdk/etdump:etdump_flatcc
-    ```
-    When compiling their binary through Buck, users can pass in this buck config to enable the pre-processor flag. For example, when compiling `sdk_example_runner` to enable ETDump generation, users compile using the following command:
-    ```
-    buck2 build -c executorch.event_tracer_enabled=true examples/sdk/sdk_example_runner:sdk_example_runner
-    ```
-
-    ii). ***CMake***
-
-    In CMake, users add this to their compile flags:
-    ```
-    -DET_EVENT_TRACER_ENABLED
-    ```
-
-    This flag needs to be added to the ExecuTorch library and any operator library that the users are compiling into their binary. For reference, users can take a look at `examples/sdk/CMakeLists.txt`. The lines of of interest are:
-    ```
-    target_compile_options(executorch PUBLIC -DET_EVENT_TRACER_ENABLED)
-    target_compile_options(portable_ops_lib PUBLIC -DET_EVENT_TRACER_ENABLED)
-    ```
+4. ***Compile*** your binary using CMake with the `ET_EVENT_TRACER_ENABLED` pre-processor flag to enable events to be traced and logged into ETDump inside the ExecuTorch runtime. This flag needs to be added to the ExecuTorch library and any operator library that you are compiling into your binary. For reference, you can take a look at `examples/sdk/CMakeLists.txt`. The lines of interest are:
+```
+target_compile_options(executorch INTERFACE -DET_EVENT_TRACER_ENABLED)
+target_compile_options(portable_ops_lib INTERFACE -DET_EVENT_TRACER_ENABLED)
+```
 ## Using an ETDump
 
-1. Pass this ETDump into the [Inspector API](./sdk-inspector.rst) to access this data and  do post-run analysis.
+Pass this ETDump into the [Inspector API](./sdk-inspector.rst) to access this data and do post-run analysis.

docs/source/sdk-etrecord.rst

@@ -29,7 +29,7 @@ the ExecuTorch program (returned by the call to ``to_executorch()``), and option
 they are interested in working with via our tooling.
 
 .. warning::
-    Users should do a deepcopy of the output of to_edge() and pass in the deepcopy to the generate_etrecord API. This is needed because the subsequent call, to_executorch(), does an in-place mutation and will lose debug data in the process.
+    Users should do a deepcopy of the output of ``to_edge()`` and pass in the deepcopy to the ``generate_etrecord`` API. This is needed because the subsequent call, ``to_executorch()``, does an in-place mutation and will lose debug data in the process.
 
 .. currentmodule:: executorch.sdk.etrecord._etrecord
 .. autofunction:: generate_etrecord

docs/source/sdk-overview.md

@@ -14,7 +14,7 @@ The ExecuTorch SDK supports the following features:
     - Model loading and execution time
 - **Delegate Integration** - Surfacing performance details from delegate backends
     - Link back delegate operator execution to the nodes they represent in the edge dialect graph (and subsequently linking back to source code and module hierarchy)
-- **Debugging** (Intermediate outputs and output quality analysis) - Coming soon
+- **Debugging** - Intermediate outputs and output quality analysis
 - **Visualization** - Coming soon
 
 ## Fundamental components of the SDK