cj-tauri 2.0.0 → 2.1.0

package/cjpm.toml

@@ -1,52 +1,63 @@
-[package]
-  cjc-version = "1.0.5"
-  name = "cjTauri"
-  description = "仓颉版 Tauri：轻量跨端混合开发框架（WebView 宿主 + IPC 桥 + 能力安全模型）"
-  version = "2.0.0"
-  target-dir = ""
-  output-type = "static"
-  compile-option = ""
-  override-compile-option = ""
-  link-option = ""
-  package-configuration = {}
-
-[dependencies]
-
-[target.x86_64-unknown-linux-gnu]
-  # -lsqlite3：sqlite 插件直连发行版系统库（D-018 第 8 条）；Windows 侧未落地，故 mingw 段不加
-  link-option = "-Lnative -lcjtbridge -lsqlite3 -lwebkit2gtk-4.1 -lgtk-3 -lgdk-3 -lglib-2.0 -lgio-2.0 -lsoup-3.0 -ljavascriptcoregtk-4.1 -lgobject-2.0"
-
-[target.x86_64-unknown-linux-gnu.bin-dependencies]
-    path-option = ["${CANGJIE_STDX}"]
-
-[target.x86_64-w64-mingw32]
-  # -lsqlite3：sqlite 插件子包需要（导入库 libsqlite3.a 由 sqlite3.def 生成，DLL 本身不入库——
-  # 跑 sqlite 相关测试/应用时本机自备 native/sqlite3.dll；不碰 sqlite 的应用不引用它就不链接）
-  link-option = "-Lnative -lcjtbridge -lsqlite3"
-
-[target.x86_64-w64-mingw32.bin-dependencies]
-    path-option = ["${CANGJIE_STDX}"]
-
-[target.aarch64-linux-ohos]
-  # 鸿蒙目标（真机 / 鸿蒙 PC）：交叉编译工具链与 sysroot 由 DevEco 仓颉套件提供，
-  # 四个路径全部走环境变量展开——hvigor 构建时由插件注入前两个，命令行交叉编译时自行 export 同名变量。
-  # 照抄 DevEco 生成的工程（TestCj2）同一串参数，避免两套口径。
-  # 末尾的 `--dy-std` 不可省：鸿蒙上应用模块（entry）是 `output-type = "dynamic"` 且用动态 std，
-  # 框架包若按默认的静态 std 编，两者混进同一个 .so 就会出现**两套 std 运行时**——表象是
-  # 启动即崩在框架包全局初始化（`cjTauri::package_global_init` → 跨包 `_CGP*` 包初始化符号
-  # 解析到模块内偏移、跳到未映射地址 0x50xxx），窗口起不来且 hilog 只有一行 SIGSEGV。
-  # 只加在鸿蒙段：桌面两平台仍是静态 std，产物形态不变。
-  compile-option = "-B \"${DEVECO_CANGJIE_HOME}/build-tools/third_party/llvm/bin\" -B \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/clang/15.0.4/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/aarch64-linux-ohos\" --sysroot \"${DEVECO_OH_NATIVE_HOME}/sysroot\" --dy-std"
-
-[target.aarch64-linux-ohos.bin-dependencies]
-    # stdx 必须用鸿蒙版（官方发布 cangjie-stdx-ohos-aarch64-<cjc 版本>.zip，桌面版 ABI 不通）；
-    # CANGJIE_OHOS_LIBS 指 DevEco 套件的 api/lib/linux_ohos_aarch64_cjnative/ohos（仓颉标准库 + ohos API 绑定）。
-    #
-    # 后两项是 ArkUI 的**宏库**与 kit 绑定，hvigor 构建时由 cangjie-build-support 注入
-    # （cangjie-path-impl.js 的 getBuildEnvByAbi）：AARCH64_MACRO_LIBS = <sdk>/api/macro/ohos
-    # （`lib-macro_ohos.arkui.state_macro_manage.dll` 就在里面），AARCH64_KIT_LIBS =
-    # .../linux_ohos_aarch64_cjnative/kit。**宏库目录漏挂的症状极具误导性**：`@Component` 的
-    # 声明能解析到（.cjo 在 ohos 目录里），但宏实现库找不到，报的是
-    # `macro evaluation has failed for macro call 'Component'`——看着像「宏不能用在框架包里」。
-    # 命令行交叉编译时这两个变量要自己 export，取值见上。
-    path-option = ["${CANGJIE_STDX_OHOS}", "${CANGJIE_OHOS_LIBS}", "${AARCH64_MACRO_LIBS}", "${AARCH64_KIT_LIBS}"]
+[package]
+  cjc-version = "1.0.5"
+  name = "cjTauri"
+  description = "仓颉版 Tauri：轻量跨端混合开发框架（WebView 宿主 + IPC 桥 + 能力安全模型）"
+  version = "2.1.0"
+  target-dir = ""
+  output-type = "static"
+  compile-option = ""
+  override-compile-option = ""
+  link-option = ""
+  package-configuration = {}
+
+[dependencies]
+
+[target.x86_64-unknown-linux-gnu]
+  # -lsqlite3：sqlite 插件直连发行版系统库（D-018 第 8 条）；Windows 侧未落地，故 mingw 段不加
+  link-option = "-Lnative -lcjtbridge -lsqlite3 -lwebkit2gtk-4.1 -lgtk-3 -lgdk-3 -lglib-2.0 -lgio-2.0 -lsoup-3.0 -ljavascriptcoregtk-4.1 -lgobject-2.0"
+
+[target.x86_64-unknown-linux-gnu.bin-dependencies]
+    path-option = ["${CANGJIE_STDX}"]
+
+[target.x86_64-w64-mingw32]
+  # -lsqlite3：sqlite 插件子包需要（导入库 libsqlite3.a 由 sqlite3.def 生成，DLL 本身不入库——
+  # 跑 sqlite 相关测试/应用时本机自备 native/sqlite3.dll；不碰 sqlite 的应用不引用它就不链接）
+  link-option = "-Lnative -lcjtbridge -lsqlite3"
+
+[target.x86_64-w64-mingw32.bin-dependencies]
+    path-option = ["${CANGJIE_STDX}"]
+
+[target.aarch64-linux-ohos]
+  # 鸿蒙目标（真机 / 鸿蒙 PC）：交叉编译工具链与 sysroot 由 DevEco 仓颉套件提供，
+  # 四个路径全部走环境变量展开——hvigor 构建时由插件注入前两个，命令行交叉编译时自行 export 同名变量。
+  # 照抄 DevEco 生成的工程（TestCj2）同一串参数，避免两套口径。
+  # 末尾的 `--dy-std` 不可省：鸿蒙上应用模块（entry）是 `output-type = "dynamic"` 且用动态 std，
+  # 框架包若按默认的静态 std 编，两者混进同一个 .so 就会出现**两套 std 运行时**——表象是
+  # 启动即崩在框架包全局初始化（`cjTauri::package_global_init` → 跨包 `_CGP*` 包初始化符号
+  # 解析到模块内偏移、跳到未映射地址 0x50xxx），窗口起不来且 hilog 只有一行 SIGSEGV。
+  # 只加在鸿蒙段：桌面两平台仍是静态 std，产物形态不变。
+  compile-option = "-B \"${DEVECO_CANGJIE_HOME}/build-tools/third_party/llvm/bin\" -B \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/sysroot/usr/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/clang/15.0.4/lib/aarch64-linux-ohos\" -L \"${DEVECO_OH_NATIVE_HOME}/llvm/lib/aarch64-linux-ohos\" --sysroot \"${DEVECO_OH_NATIVE_HOME}/sysroot\" --dy-std"
+
+  # -lpasteboard -ludmf：剪贴板宿主能力直连系统粘贴板服务（`src/clipboard_bridge.cj` 的鸿蒙段用
+  # `OH_Pasteboard_*` / `OH_Udmf*` / `OH_UdsPlainText_*` 原生 C API——仓颉套件里没有 `ohos.pasteboard`
+  # 包，6.1 的 ohos 包里 340 个都没有它，只有旧的 5.0 Beta 带）。两组符号分属两个库
+  # （`OH_Pasteboard_*` 在 libpasteboard、其余在 libudmf），所以两个都要给。
+  # 库就在同一 sysroot 的 `usr/lib/aarch64-linux-ohos`（上面的 `-L` 已指着），运行时由系统提供
+  # （设备侧落在 `/system/lib64/ndk/`，DT_NEEDED 由 loader 在 ndk 命名空间里解析）。
+  # 注意：**真正生效的开关在 entry 模块的 cjpm.toml**（`output-type = dynamic`，链接发生在那儿）；
+  # `cli/src/manifest.cj` 的 `renderOhosEntryToml` 会把它写进 `targets/ohos/entry/cjpm.toml`。
+  # 这里留着是给「直接 cjpm 交叉编译框架」的口径一致，漏了不影响 hap 构建。
+  link-option = "-lpasteboard -ludmf"
+
+[target.aarch64-linux-ohos.bin-dependencies]
+    # stdx 必须用鸿蒙版（官方发布 cangjie-stdx-ohos-aarch64-<cjc 版本>.zip，桌面版 ABI 不通）；
+    # CANGJIE_OHOS_LIBS 指 DevEco 套件的 api/lib/linux_ohos_aarch64_cjnative/ohos（仓颉标准库 + ohos API 绑定）。
+    #
+    # 后两项是 ArkUI 的**宏库**与 kit 绑定，hvigor 构建时由 cangjie-build-support 注入
+    # （cangjie-path-impl.js 的 getBuildEnvByAbi）：AARCH64_MACRO_LIBS = <sdk>/api/macro/ohos
+    # （`lib-macro_ohos.arkui.state_macro_manage.dll` 就在里面），AARCH64_KIT_LIBS =
+    # .../linux_ohos_aarch64_cjnative/kit。**宏库目录漏挂的症状极具误导性**：`@Component` 的
+    # 声明能解析到（.cjo 在 ohos 目录里），但宏实现库找不到，报的是
+    # `macro evaluation has failed for macro call 'Component'`——看着像「宏不能用在框架包里」。
+    # 命令行交叉编译时这两个变量要自己 export，取值见上。
+    path-option = ["${CANGJIE_STDX_OHOS}", "${CANGJIE_OHOS_LIBS}", "${AARCH64_MACRO_LIBS}", "${AARCH64_KIT_LIBS}"]

package/cli/cjpm.toml

@@ -1,22 +1,22 @@
-[package]
-  cjc-version = "1.0.5"
-  name = "cli"
-  description = "cj-tauri CLI：脚手架 create / dev / build / run / info"
-  version = "2.0.0"
-  target-dir = ""
-  output-type = "executable"
-  compile-option = ""
-  override-compile-option = ""
-  link-option = ""
-  package-configuration = {}
-
-[dependencies]
-
-[target.x86_64-unknown-linux-gnu.bin-dependencies]
-  path-option = ["${CANGJIE_STDX}"]
-
-[target.x86_64-w64-mingw32.bin-dependencies]
-  # 与根 cjpm.toml 同口径：CLI 也 import stdx.encoding.json，Windows 上缺这一段时
-  # cjpm 报的是 `root package 'cli' imports package 'stdx.encoding.json' … not added as a
-  # dependency in cjpm.toml`（看着像 toml 漏配，其实是 Windows 目标段没声明 stdx）。
-  path-option = ["${CANGJIE_STDX}"]
+[package]
+  cjc-version = "1.0.5"
+  name = "cli"
+  description = "cj-tauri CLI：脚手架 create / dev / build / run / info"
+  version = "2.1.0"
+  target-dir = ""
+  output-type = "executable"
+  compile-option = ""
+  override-compile-option = ""
+  link-option = ""
+  package-configuration = {}
+
+[dependencies]
+
+[target.x86_64-unknown-linux-gnu.bin-dependencies]
+  path-option = ["${CANGJIE_STDX}"]
+
+[target.x86_64-w64-mingw32.bin-dependencies]
+  # 与根 cjpm.toml 同口径：CLI 也 import stdx.encoding.json，Windows 上缺这一段时
+  # cjpm 报的是 `root package 'cli' imports package 'stdx.encoding.json' … not added as a
+  # dependency in cjpm.toml`（看着像 toml 漏配，其实是 Windows 目标段没声明 stdx）。
+  path-option = ["${CANGJIE_STDX}"]