Wrap DEPENDENCIES.md into building.md, fix discrepancies

docs/building.md

@@ -215,15 +215,18 @@ After a successful build:
 ```
 build-release/
 ├── lib/
-│   ├── liblivekit.{a,lib}          # Main SDK static library
-│   ├── liblivekit_ffi.{so,dylib}   # Rust FFI dynamic library
-│   └── livekit_ffi.dll, *.lib      # (Windows) FFI DLL + import lib
+│   ├── liblivekit.{so,dylib}       # Main SDK shared library (Linux/macOS)
+│   ├── liblivekit_ffi.{so,dylib}   # Rust FFI shared library (Linux/macOS)
+│   └── livekit{,_ffi}.lib          # Import libraries (Windows)
 ├── include/                        # Public headers (auto-synced)
 │   └── livekit/
-└── bin/                            # Example/test executables
-    └── liblivekit_ffi.{so,dylib}   # (Linux/macOS: copied for runtime)
+└── bin/
+    └── livekit{,_ffi}.dll          # SDK DLLs (Windows)
 ```
 
+Release archives use the same layout: `include/`, `lib/`, and (on Windows)
+`bin/`. The exact build-tree layout can vary with the CMake generator.
+
 ## Integrating into your project
 
 ### Using CMake
@@ -234,8 +237,8 @@ add_subdirectory(path/to/client-sdk-cpp)
 target_link_libraries(your_target PRIVATE livekit)
 
 # Method 2: find_package (after install)
-find_package(livekit REQUIRED)
-target_link_libraries(your_target PRIVATE livekit)
+find_package(LiveKit CONFIG REQUIRED)
+target_link_libraries(your_target PRIVATE LiveKit::livekit)
 ```
 
 ### Using prebuilt releases
@@ -252,53 +255,44 @@ See the example collection's
 [`LiveKitSDK.cmake`](https://github.com/livekit-examples/cpp-example-collection/blob/main/cmake/LiveKitSDK.cmake)
 for the full pattern.
 
-### Manual linking
-
-1. Add include path: `build-release/include`
-2. Link the static SDK library:
-   - Windows: `build-release/lib/livekit.lib`
-   - Linux: `build-release/lib/liblivekit.a`
-   - macOS: `build-release/lib/liblivekit.a`
-3. Link/deploy the Rust FFI dynamic library:
-   - Windows: link `livekit_ffi.dll.lib`, deploy `livekit_ffi.dll` next to your `.exe`
-   - Linux: deploy `liblivekit_ffi.so` next to your executable
-   - macOS: deploy `liblivekit_ffi.dylib` next to your executable
-4. Link platform system libraries (see below).
-
-> **Important:** On Linux/macOS the FFI shared library must live next to the
-> executable. RPATH is set to `$ORIGIN` (Linux) / `@loader_path` (macOS).
-
-**Windows system libraries:**
-```
-ntdll userenv winmm iphlpapi msdmo dmoguids wmcodecdspuuid
-ws2_32 secur32 bcrypt crypt32
-```
-
-**macOS frameworks:**
-```
-CoreAudio AudioToolbox CoreFoundation Security CoreGraphics
-CoreMedia VideoToolbox AVFoundation CoreVideo Foundation
-AppKit QuartzCore OpenGL IOSurface Metal MetalKit ScreenCaptureKit
-```
-
-**Linux libraries:**
-```
-OpenSSL::SSL OpenSSL::Crypto
-```
-
-### Runtime dependencies of prebuilt artifacts
-
-Whether protobuf / abseil / openssl need to be installed on the target
-machine depends on how the SDK binary was built:
-
-- **Windows** release artifacts use vcpkg triplet `x64-windows-static-md` —
-  protobuf and abseil are statically linked into the DLLs; no runtime install
-  needed.
-- **macOS** release artifacts (from our CI) do **not** dynamically depend on
-  protobuf / abseil / openssl. You can verify with `otool -L liblivekit.dylib`.
-- **Linux** depends on packaging. Check with `ldd liblivekit_ffi.so`; if any
-  of those are listed, install the corresponding `-dev` (build) or runtime
-  package (`libprotobuf32` / `libabsl` / `libssl3`) as appropriate.
+### Manual linking and deployment
+
+Prefer the CMake package above. It provides the correct include directory and
+the `LiveKit::livekit` shared-library target. If you link a release archive
+manually, add its `include/` directory and link only the main SDK library:
+
+| Platform | Link-time file | Runtime files to deploy |
+|----------|----------------|-------------------------|
+| Windows | `lib/livekit.lib` | `bin/livekit.dll` and `bin/livekit_ffi.dll` beside the application executable |
+| Linux | `lib/liblivekit.so` | `liblivekit.so` and `liblivekit_ffi.so` in the same runtime-library directory |
+| macOS | `lib/liblivekit.dylib` | `liblivekit.dylib` and `liblivekit_ffi.dylib` in the same runtime-library directory |
+
+Do not link the Rust FFI library directly: `livekit` already records it as a
+shared-library dependency. On Linux, `liblivekit.so` uses a `$ORIGIN` runpath
+to locate `liblivekit_ffi.so` next to it. On macOS, it uses `@loader_path` for
+the same purpose. Your application must still be configured to find
+`liblivekit` at runtime (for example, by using an appropriate executable
+RPATH or platform packaging mechanism).
+
+### Runtime dependencies of release artifacts
+
+Official release archives bundle the two SDK libraries above. They do not
+bundle, or dynamically depend on, Protobuf, Abseil, or OpenSSL. As of v1.7.0:
+
+- **Windows:** the SDK DLLs depend on Windows system libraries and the
+  Microsoft Visual C++ runtime. Install the supported Visual C++ Redistributable
+  with your application when it is not already present. The archive contains no
+  Protobuf or Abseil DLLs.
+- **Linux:** `liblivekit.so` additionally depends on the system C++ runtime,
+  glibc, and `libcurl.so.4`; `liblivekit_ffi.so` depends on the system C++
+  runtime and glibc. Install the matching runtime packages for your target
+  distribution.
+- **macOS:** the SDK depends on system frameworks and the system `libcurl`;
+  no Homebrew Protobuf, Abseil, or OpenSSL runtime is required.
+
+These are release-artifact requirements, not source-build prerequisites. For
+an updated audit of a specific release, inspect its binaries with `ldd`
+(Linux), `otool -L` (macOS), or `dumpbin /dependents` (Windows).
 
 ## Troubleshooting