Build every binding against the repository's core; drop cxx_impl

The Flutter, Rust and C# bindings each embedded core as a cxx_impl
submodule, so a core change meant moving three extra pointers. They now
build the repository's core/ directly: the Rust build.rs, the Flutter
plugin's CMake (resolving Flutter's .plugin_symlinks first) and the C#
native CMake point at it, and the Apple source wrappers, umbrella headers
and ffigen.yaml are regenerated with core-relative paths. codegen sync no
longer has anything to move per binding.

Published packages still need core's sources inside them. The release
workflows copy core into cxx_impl/ (never committed); build.rs and the
plugin CMake prefer that copy when present, and the Flutter workflow
points the Apple wrappers at it with `codegen.py --core-dir ...
--sources-only` in a local commit that is not pushed, since
`dart pub publish` warns about modified checked-in files. CI checks out
only core and also runs when the core pointer moves.

Author: lijy91

.agents/skills/core-api-change/SKILL.md

@@ -5,8 +5,7 @@ description: Carry a change to the C++ public API in core/ all the way downstrea
 
 # core-api-change
 
-`./codegen sync` does the mechanical half: regenerate, bump each binding's embedded core,
-rerun bindgen / ffigen, commit core and the workspace. This skill is the other half — the decisions
+`./codegen sync` does the mechanical half: regenerate, rerun bindgen / ffigen, commit core and the workspace. This skill is the other half — the decisions
 and checks the script cannot make. Work through the phases in order; each one ends in
 something you can verify before moving on.
 
@@ -140,18 +139,16 @@ skill rather than trusting the compile.
 ```
 
 It commits core with your message, then the workspace as `Sync with core <sha9>`: the
-core pointer plus everything regenerated under `bindings/` and each binding's `cxx_impl`
-gitlink. It does not push.
+core pointer plus everything regenerated under `bindings/`. The bindings build against
+`core/` directly, so there is no per-binding copy of core to move. It does not push.
 
 **A binding has unrelated work — manual path.** Same steps, staged narrowly:
 
 1. Commit core yourself (`git -C core add <paths> && git -C core commit -m ...`).
-2. In each binding: update the embedded core submodule (`cxx_impl`) to that sha,
-   fetching from the local `core/`; rust → rerun bindgen (command in
-   `tools/codegen/README.md`); flutter → `python3 codegen.py --no-submodule-update` in
-   `bindings/flutter/cnativeapi`.
-3. Workspace: `git add core` plus only the generated paths and the `cxx_impl` gitlinks
-   under `bindings/`; commit as `Sync with core <sha9>`.
+2. `./codegen`; rust → rerun bindgen (command in `tools/codegen/README.md`); flutter →
+   `python3 codegen.py` in `bindings/flutter/cnativeapi`.
+3. Workspace: `git add core` plus only the generated paths under `bindings/`; commit as
+   `Sync with core <sha9>`.
 
 Either way: no Co-Authored-By trailers; after staging, read `git status --short` and
 `git diff --cached --stat` in each repo **before** committing — a file you did not write

.agents/skills/record-demo/SKILL.md

@@ -85,7 +85,7 @@ saved video or an `ERROR`.
   optional: the test laptop's scoop was broken (self-update fails, the 7zip dependency
   would not install), and winget asks to accept agreements.
 - The apps must already be built there in debug (see `remote-hosts`), from the checkout
-  you mean to show — check that submodules such as the Flutter binding's `cxx_impl` are
+  you mean to show — check that the `core` submodule is
   actually checked out at the recorded commit (`git submodule update`), not just
   pointed at it.
 - **The whole screen is in the picture.** Before recording, look at the desktop

.agents/skills/remote-hosts/references/windows.md

@@ -45,9 +45,8 @@ $ErrorActionPreference = "Stop"
 
 - Same layout as here (`core/`, `bindings/*` on `main`). Get changes there with
   `git pull` in each repo — but **GitHub over HTTPS is flaky from that network**.
-  For unpushed or unreachable commits, fetch between local checkouts instead (for the
-  Flutter binding's nested core: `git -C …\cxx_impl fetch $RemoteWorkspace\core main`),
-  or `scp` a patch / the changed files.
+  For unpushed or unreachable commits, fetch between local checkouts instead
+  (`git -C …\core fetch <another checkout> main`), or `scp` a patch / the changed files.
 - Tooling: VS 2022 (generator `"Visual Studio 17 2022" -A x64`; there is no ninja),
   CMake, Python 3, Flutter via fvm. The `fvm\default` junction does not resolve over
   SSH — point `HOST_PATH_PREPEND` at a concrete `fvm\versions\<channel>\bin`. The
@@ -63,8 +62,8 @@ $ErrorActionPreference = "Stop"
 - `core.autocrlf` makes `git status` noisy and `flutter pub get` rewrites
   `analysis_options.yaml` files. Judge real changes with
   `git diff --ignore-cr-at-eol --stat`.
-- **Leave it as you found it.** Record `git status --short` for the workspace,
-  `core` and `bindings/flutter/cnativeapi/cxx_impl` *before* you start; at the end
+- **Leave it as you found it.** Record `git status --short` for the workspace
+  and `core` *before* you start; at the end
   `git checkout --` only the files you touched and compare. Pre-existing local
   changes on that machine are the user's — do not revert them.
 

.github/workflows/csharp-ci.yml

@@ -5,12 +5,14 @@ on:
     branches: [main]
     paths:
       - "bindings/csharp/**"
+      - "core"
       - "examples/csharp_*/**"
       - ".github/workflows/csharp-ci.yml"
   pull_request:
     branches: [main]
     paths:
       - "bindings/csharp/**"
+      - "core"
       - "examples/csharp_*/**"
       - ".github/workflows/csharp-ci.yml"
   workflow_dispatch:
@@ -37,9 +39,9 @@ jobs:
     timeout-minutes: 15
     steps:
       - uses: actions/checkout@v4
-      - name: Checkout C# binding submodules
+      - name: Checkout core
         working-directory: .
-        run: git submodule update --init --recursive -- bindings/csharp
+        run: git submodule update --init core
       - uses: actions/setup-dotnet@v4
         with:
           dotnet-version: |
@@ -67,9 +69,9 @@ jobs:
             library: build/native/Release/nativeapi.dll
     steps:
       - uses: actions/checkout@v4
-      - name: Checkout C# binding submodules
+      - name: Checkout core
         working-directory: .
-        run: git submodule update --init --recursive -- bindings/csharp
+        run: git submodule update --init core
       - uses: actions/setup-dotnet@v4
         with:
           dotnet-version: |

.github/workflows/flutter-ci.yml

@@ -5,13 +5,15 @@ on:
     branches: [ main, ohos-main ]
     paths:
       - "bindings/flutter/**"
+      - "core"
       - "examples/flutter_*/**"
       - "pubspec.yaml"
       - ".github/workflows/flutter-ci.yml"
   pull_request:
     branches: [ main, ohos-main ]
     paths:
       - "bindings/flutter/**"
+      - "core"
       - "examples/flutter_*/**"
       - "pubspec.yaml"
       - ".github/workflows/flutter-ci.yml"
@@ -25,10 +27,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2
@@ -67,10 +67,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2
@@ -110,10 +108,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2
@@ -157,10 +153,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2
@@ -198,10 +192,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2
@@ -253,10 +245,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2
@@ -294,10 +284,8 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      # Only the Flutter binding's submodules: the root ones (core, other
-      # bindings) are not needed here and some use SSH URLs.
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       - name: Setup Flutter
         uses: subosito/flutter-action@v2

.github/workflows/flutter-publish.yml

@@ -16,8 +16,8 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
-      - name: Checkout Flutter submodules
-        run: git submodule update --init --recursive -- bindings/flutter
+      - name: Checkout core
+        run: git submodule update --init core
 
       # Set up the Dart SDK and provision the OIDC token used for publishing.
       - uses: dart-lang/setup-dart@65eb853c7ba17dde3be364c3d2858773e7144260
@@ -29,6 +29,18 @@ jobs:
           channel: stable
           version: 3.47.5
 
+      # The cnativeapi package must carry core's sources: copy them into
+      # cxx_impl/ (untracked; the CMake build prefers it when present) and point
+      # the Apple source wrappers there. The rewritten wrappers go into a local
+      # commit that is never pushed, because `dart pub publish` warns about
+      # modified checked-in files.
+      - name: Vendor core into cnativeapi
+        run: |
+          mkdir bindings/flutter/cnativeapi/cxx_impl
+          git -C core archive HEAD | tar -x -C bindings/flutter/cnativeapi/cxx_impl
+          python3 bindings/flutter/cnativeapi/codegen.py --core-dir bindings/flutter/cnativeapi/cxx_impl --sources-only
+          git -c user.name=release -c user.email=release@localhost commit -qam "Point cnativeapi at its vendored core (not pushed)"
+
       # Publish cnativeapi
       - name: Install dependencies (cnativeapi)
         run: dart pub get

.github/workflows/rust-ci.yml

@@ -5,6 +5,7 @@ on:
     branches: [main]
     paths:
       - "bindings/rust/**"
+      - "core"
       - "examples/rust_*/**"
       - "Cargo.toml"
       - "Cargo.lock"
@@ -13,6 +14,7 @@ on:
     branches: [main]
     paths:
       - "bindings/rust/**"
+      - "core"
       - "examples/rust_*/**"
       - "Cargo.toml"
       - "Cargo.lock"
@@ -36,8 +38,8 @@ jobs:
     timeout-minutes: 20
     steps:
       - uses: actions/checkout@v4
-      - name: Checkout Rust binding submodules
-        run: git submodule update --init --recursive -- bindings/rust
+      - name: Checkout core
+        run: git submodule update --init core
       - uses: dtolnay/rust-toolchain@stable
         with:
           components: rustfmt, clippy
@@ -59,8 +61,8 @@ jobs:
         os: [ubuntu-latest, macos-latest, windows-latest]
     steps:
       - uses: actions/checkout@v4
-      - name: Checkout Rust binding submodules
-        run: git submodule update --init --recursive -- bindings/rust
+      - name: Checkout core
+        run: git submodule update --init core
       - uses: dtolnay/rust-toolchain@stable
       - name: Install Linux dependencies
         if: runner.os == 'Linux'

.github/workflows/rust-release.yml

@@ -22,8 +22,8 @@ jobs:
       contents: write
     steps:
       - uses: actions/checkout@v4
-      - name: Checkout Rust binding submodules
-        run: git submodule update --init --recursive -- bindings/rust
+      - name: Checkout core
+        run: git submodule update --init core
       - uses: dtolnay/rust-toolchain@stable
       - uses: actions/setup-python@v5
         with:
@@ -47,15 +47,22 @@ jobs:
       - uses: Swatinem/rust-cache@v2
       - name: Test release sources
         run: cargo test --workspace --release --locked
+      # A published crate cannot reach the repository's core/, so cnativeapi
+      # carries a copy in cxx_impl/ (build.rs prefers it when present). It is
+      # untracked, hence --allow-dirty for that crate.
+      - name: Vendor core into cnativeapi
+        run: |
+          mkdir bindings/rust/cnativeapi/cxx_impl
+          git -C core archive HEAD | tar -x -C bindings/rust/cnativeapi/cxx_impl
       - name: Verify packaged native sources build outside the checkout
-        run: cargo package -p cnativeapi --locked
+        run: cargo package -p cnativeapi --locked --allow-dirty
       - name: Publish crates in dependency order
         if: github.event_name == 'push' && github.ref_type == 'tag'
         env:
           CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}
         run: |
           test -n "$CARGO_REGISTRY_TOKEN"
-          cargo publish -p cnativeapi --locked
+          cargo publish -p cnativeapi --locked --allow-dirty
           cargo publish -p nativeapi --locked
       - uses: actions/upload-artifact@v4
         with:

.gitmodules

@@ -2,12 +2,3 @@
 	path = core
 	url = ../nativeapi-core.git
 	branch = main
-[submodule "packages/cnativeapi/cxx_impl"]
-	path = bindings/flutter/cnativeapi/cxx_impl
-	url = https://github.com/libnativeapi/nativeapi-core.git
-[submodule "crates/cnativeapi/cxx_impl"]
-	path = bindings/rust/cnativeapi/cxx_impl
-	url = https://github.com/libnativeapi/nativeapi-core.git
-[submodule "cxx_impl"]
-	path = bindings/csharp/src/CNativeAPI/cxx_impl
-	url = https://github.com/libnativeapi/nativeapi-core.git

AGENTS.md

@@ -24,7 +24,7 @@ codegen             # Python entry point orchestrating the generators
 
 - `core` — the C++ core library (repo: `nativeapi-core`). The source of truth for the native API surface (windows, tray icons, menus, displays, keyboard, dialogs, storage, etc.) with per-platform implementations (macOS/Windows/Linux).
 - `tools/codegen` — three crates: `shared` (libclang parser, IR, naming), `capi` (C ABI + umbrella header), `bindings` (Rust/Dart/C# generators, consuming the IR JSON emitted by `capi`). Only `capi` depends on libclang. See tools/codegen/README.md.
-- `bindings/*` — language bindings wrapping the core library. All live in this repo. Each embeds the core repo as a submodule (`cxx_impl`) so its packages build standalone. The Rust binding layers `crates/nativeapi` (safe API) over `crates/cnativeapi` (FFI).
+- `bindings/*` — language bindings wrapping the core library. All live in this repo and build against the `core/` submodule directly (Rust `build.rs`, the Flutter plugin's CMake and generated Apple source wrappers, the C# native CMake). Only a published package carries its own copy of core, in `cxx_impl/`, which the release workflows vendor and never commit. The Rust binding layers `nativeapi` (safe API) over `cnativeapi` (FFI).
 
 ## Design specs
 
@@ -63,7 +63,7 @@ A core change ripples to every binding. After editing headers in `core`, run:
 ./codegen sync -m "<core commit message>"
 ```
 
-It regenerates everything, updates each binding's embedded core submodule (fetched from the local `core/`, so no push is required first), reruns `bindgen` (Rust raw FFI) and the flutter binding's `codegen.py` (umbrella headers + ffigen), then commits core and this repo (`Sync with core <sha>`: the core pointer plus everything regenerated under `bindings/`). Add `--push` to publish in dangling-safe order (core → workspace).
+It regenerates everything, reruns `bindgen` (Rust raw FFI) and the flutter binding's `codegen.py` (umbrella headers + ffigen), then commits core and this repo (`Sync with core <sha>`: the core pointer plus everything regenerated under `bindings/`). Add `--push` to publish in dangling-safe order (core → workspace).
 
 Manual follow-ups sync cannot do (details in tools/codegen/README.md):
 
@@ -90,7 +90,7 @@ scenarios for *this project's* examples live in [tools/gui/](tools/gui/README.md
 
 ## Conventions
 
-- `core` tracks `branch = main`. Use `make sync` to fast-forward it; `make status` to see dirty state everywhere; `make bump` to stage its pointer. Each binding's embedded core (`cxx_impl`) is moved by `./codegen sync` or by hand, never by `make`.
+- `core` tracks `branch = main`. Use `make sync` to fast-forward it; `make status` to see dirty state everywhere; `make bump` to stage its pointer.
 - The leanflutter packages built on nativeapi (`tray_manager`, `window_manager`, `launch_at_startup`, …) live in their own repos under github.com/leanflutter and depend on the published `nativeapi`; they are not part of this repo. To try one against local changes, point a `dependency_overrides` entry in that package at `bindings/flutter/nativeapi` (and `cnativeapi`) and never commit the override.
 - Commit workspace submodule pointer updates only when the combination is compatible (a known-good snapshot).
 - Examples live in `examples/<binding>_<name>_example` (`flutter_`, `rust_`, `csharp_`), not inside the bindings; a new Flutter or Rust example must also be listed in the root `pubspec.yaml` / `Cargo.toml`, a C# one in `bindings/csharp/NativeAPI.slnx`. Only the pub.dev package examples (`bindings/flutter/*/example`) stay inside their package.