Fix Windows build failure on non-UTF-8 locales (C4819/C2220)

src/serious_python/CHANGELOG.md

@@ -1,3 +1,8 @@
+## 4.3.3
+
+* **Windows:** fix `flet build windows` failing on non-UTF-8 system locales (e.g. Simplified-Chinese Windows, code page **936/GBK**) with `error C2220` (escalated from `warning C4819`) while compiling the Windows plugin — a non-ASCII character in a source comment couldn't be decoded under GBK and the Flutter template's `/WX` made it fatal. The character is removed and the plugin now builds with `/utf-8`. See `serious_python_windows` 4.3.3 and flet-dev/flet#6686.
+* No runtime changes: bundled Python versions (**3.12.13 / 3.13.14 / 3.14.6**) and `dart_bridge` (**1.5.0**) are unchanged from 4.3.2.
+
 ## 4.3.2
 
 * **iOS:** interdependent bundled dylibs (e.g. pyarrow, llama-cpp-python) no longer crash the app at launch with `dyld: Library not loaded: @rpath/lib<X>.dylib` — the framework install-ids and sibling `@rpath` references are reconciled to the relocated framework paths ([#223](https://github.com/flet-dev/serious-python/issues/223)). See `serious_python_darwin` 4.3.2.

src/serious_python/pubspec.yaml

@@ -2,7 +2,7 @@ name: serious_python
 description: A cross-platform plugin for adding embedded Python runtime to your Flutter apps.
 homepage: https://flet.dev
 repository: https://github.com/flet-dev/serious-python
-version: 4.3.2
+version: 4.3.3
 
 platforms:
   ios:

src/serious_python_android/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.3.3
+
+* Version bump aligning with the `serious_python_*` 4.3.3 release (a Windows build fix). No Android-affecting changes.
+
 ## 4.3.2
 
 * **Resolve a package whose `__init__` is itself the native extension.** `_SorefFinder` only probed `<dotted>.soref`, so a package that ships its extension as `<pkg>/__init__.<abi>.so` — e.g. apsw (import name `apsw`), whose relocation marker lands at `apsw/__init__.soref` — was never resolved: `find_spec` returned `None`, the synthesized empty `apsw/__init__.py` won, and `import apsw` yielded an empty module (`AttributeError: module 'apsw' has no attribute 'Connection'`). `find_spec` now falls back to `<dotted>/__init__.soref`, loads the extension under the correct top-level name via `ExtensionFileLoader`, and marks the result a package (with `submodule_search_locations`) so pure-Python submodules (`apsw.ext`, …) still resolve.

src/serious_python_android/android/build.gradle.kts

@@ -21,7 +21,7 @@ buildscript {
 }
 
 group = "com.flet.serious_python_android"
-version = "4.3.2"
+version = "4.3.3"
 
 rootProject.allprojects {
     repositories {

src/serious_python_android/pubspec.yaml

@@ -2,7 +2,7 @@ name: serious_python_android
 description: Android implementation of the serious_python plugin
 homepage: https://flet.dev
 repository: https://github.com/flet-dev/serious-python
-version: 4.3.2
+version: 4.3.3
 
 environment:
   sdk: ">=3.0.0 <4.0.0"

src/serious_python_darwin/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.3.3
+
+* Version bump aligning with the `serious_python_*` 4.3.3 release (a Windows build fix). No iOS/macOS-affecting changes.
+
 ## 4.3.2
 
 * **iOS: reconcile framework install-names for interdependent bundled dylibs** ([#223](https://github.com/flet-dev/serious-python/issues/223)). Site-package `.so`/`.dylib`s are wrapped into frameworks named by their dotted relative path (`opt/lib/libarrow.dylib` → `opt.lib.libarrow.framework/opt.lib.libarrow`), but the Mach-O install-id and every interdependent `@rpath` reference were left at their original bare name (`@rpath/libarrow.dylib`). Because each framework is a `Package.swift` binaryTarget linked at launch, dyld could not resolve `@rpath/libarrow.dylib` (it looks for `Frameworks/libarrow.dylib`, which does not exist) and the app crashed **before Python started** — hitting any package that bundles a chain of interdependent libs (pyarrow's `libarrow`/`libarrow_compute`/`libarrow_python`, llama-cpp-python's `libggml*`/`libllama`). A new reconcile pass, run after `sync_site_packages` frameworks the libs, sets each framework's own install-id to `@rpath/<fw>.framework/<fw>` and rewrites every dependency pointing at a sibling's old id to that framework path, then re-signs. The Python/stdlib xcframeworks are left untouched. (This supersedes the 4.2.1 approach of preserving `.dylib` install-names, which only worked when every sibling happened to be loaded first.)

src/serious_python_darwin/darwin/serious_python_darwin.podspec

@@ -4,7 +4,7 @@
 #
 Pod::Spec.new do |s|
   s.name             = 'serious_python_darwin'
-  s.version          = '4.3.2'
+  s.version          = '4.3.3'
   s.summary          = 'A cross-platform plugin for adding embedded Python runtime to your Flutter apps.'
   s.description      = <<-DESC
   A cross-platform plugin for adding embedded Python runtime to your Flutter apps.

src/serious_python_darwin/pubspec.yaml

@@ -2,7 +2,7 @@ name: serious_python_darwin
 description: iOS and macOS implementations of the serious_python plugin
 homepage: https://flet.dev
 repository: https://github.com/flet-dev/serious-python
-version: 4.3.2
+version: 4.3.3
 
 environment:
   # The Swift Package Manager build path needs Flutter 3.44 / Dart 3.11 (the

src/serious_python_linux/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.3.3
+
+* Remove a stray non-ASCII character (an em dash) from a source comment in `serious_python_linux_plugin.cc` — GCC reads UTF-8 sources by default so there was no build impact, but it mirrors the Windows fix (flet-dev/flet#6686). Version bump aligning with the `serious_python_*` 4.3.3 release; no Linux-affecting runtime changes.
+
 ## 4.3.2
 
 * Bump the bundled python-build snapshot to `20260714`; aligns with the `serious_python_*` 4.3.2 release. The release contains only Android/iOS runtime fixes — no Linux-affecting changes.

src/serious_python_linux/linux/serious_python_linux_plugin.cc

@@ -3,7 +3,7 @@
 #include <flutter_linux/flutter_linux.h>
 #include <gtk/gtk.h>
 
-// Plugin-registration shell only — all method calls return NotImplemented.
+// Plugin-registration shell only - all method calls return NotImplemented.
 // Python lifecycle lives in libdart_bridge.so, invoked from Dart via FFI.
 
 #define SERIOUS_PYTHON_LINUX_PLUGIN(obj)                                     \

src/serious_python_linux/pubspec.yaml

@@ -2,7 +2,7 @@ name: serious_python_linux
 description: Linux implementations of the serious_python plugin
 homepage: https://flet.dev
 repository: https://github.com/flet-dev/serious-python
-version: 4.3.2
+version: 4.3.3
 
 environment:
   sdk: '>=3.1.3 <4.0.0'

src/serious_python_platform_interface/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.3.3
+
+* Version bump aligning with the `serious_python_*` 4.3.3 release.
+
 ## 4.3.2
 
 * Version bump aligning with the `serious_python_*` 4.3.2 release.

src/serious_python_platform_interface/pubspec.yaml

@@ -2,7 +2,7 @@ name: serious_python_platform_interface
 description: A common platform interface for the serious_python plugin.
 homepage: https://flet.dev
 repository: https://github.com/flet-dev/serious-python
-version: 4.3.2
+version: 4.3.3
 
 environment:
   sdk: ">=3.0.0 <4.0.0"

src/serious_python_windows/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 4.3.3
+
+* **Fix `flet build windows` failing on non-UTF-8 system locales** with `warning C4819` escalated to `error C2220` while compiling `serious_python_windows_plugin.cpp` (flet-dev/flet#6686). A source comment contained a non-ASCII character (an em dash); on a system whose code page isn't UTF-8 — e.g. code page **936/GBK** on Simplified-Chinese Windows — MSVC decodes the UTF-8 source as GBK, can't represent the byte sequence (C4819), and the Flutter template's `/WX` (warnings-as-errors) turns it into a fatal C2220. The character is removed, and the plugin now compiles with `/utf-8` so any future non-ASCII source byte is read correctly regardless of the build machine's code page. Bundled Python and `dart_bridge` versions are unchanged from 4.3.2.
+
 ## 4.3.2
 
 * Bump the bundled python-build snapshot to `20260714`; aligns with the `serious_python_*` 4.3.2 release. The release contains only Android/iOS runtime fixes — no Windows-affecting changes.

src/serious_python_windows/pubspec.yaml

@@ -2,7 +2,7 @@ name: serious_python_windows
 description: Windows implementations of the serious_python plugin
 homepage: https://flet.dev
 repository: https://github.com/flet-dev/serious-python
-version: 4.3.2
+version: 4.3.3
 
 environment:
   sdk: '>=3.1.3 <4.0.0'

src/serious_python_windows/windows/CMakeLists.txt

@@ -172,6 +172,14 @@ add_library(${PLUGIN_NAME} SHARED
 apply_standard_settings(${PLUGIN_NAME})
 target_compile_features(${PLUGIN_NAME} PRIVATE cxx_std_20)
 
+# Force MSVC to read source files as UTF-8 regardless of the build machine's
+# system code page. Without this, a non-ASCII byte anywhere in a source file
+# triggers warning C4819 on non-UTF-8 locales (e.g. code page 936/GBK on
+# Simplified-Chinese Windows), which the Flutter template's /WX
+# (warnings-as-errors) escalates to a fatal C2220 build error
+# (flet-dev/flet#6686).
+target_compile_options(${PLUGIN_NAME} PRIVATE "/utf-8")
+
 # Symbols are hidden by default to reduce the chance of accidental conflicts
 # between plugins. This should not be removed; any symbols that should be
 # exported should be explicitly exported with the FLUTTER_PLUGIN_EXPORT macro.

src/serious_python_windows/windows/serious_python_windows_plugin.cpp

@@ -36,7 +36,7 @@ namespace serious_python_windows
 
   SeriousPythonWindowsPlugin::~SeriousPythonWindowsPlugin() {}
 
-  // Plugin-registration shell only — all method calls return NotImplemented.
+  // Plugin-registration shell only - all method calls return NotImplemented.
   // Python lifecycle lives in dart_bridge[_d].dll, invoked from Dart via FFI.
   void SeriousPythonWindowsPlugin::HandleMethodCall(
       const flutter::MethodCall<flutter::EncodableValue> &method_call,