Skip to content

fix(windows): plugin builds against current Flutter Windows registrant#85

Merged
erweixin merged 2 commits into
erweixin:mainfrom
TheMystery28:fix/windows-plugin-build
May 16, 2026
Merged

fix(windows): plugin builds against current Flutter Windows registrant#85
erweixin merged 2 commits into
erweixin:mainfrom
TheMystery28:fix/windows-plugin-build

Conversation

@TheMystery28

Copy link
Copy Markdown
Contributor

Summary

Two patches that together make ratex_flutter's Windows plugin build out-of-the-box against current Flutter (verified against Flutter 3.41.9 stable / Dart 3.11.5 on Windows 10).

Bug 1 — plugin's own .cpp can't find its own header

windows/CMakeLists.txt declares target_include_directories(... INTERFACE ...). INTERFACE exposes the dir only to consumers — the plugin's own ratex_flutter_plugin.cpp cannot resolve #include "ratex_flutter/ratex_flutter_plugin.h". Fix: widen scope to PUBLIC (strict CMake superset; consumers see no behavioural change).

Bug 2 — missing C API registrant

Flutter's auto-generated generated_plugin_registrant.cc (since Flutter ~2.10) includes <ratex_flutter/ratex_flutter_plugin_c_api.h> and calls RatexFlutterPluginCApiRegisterWithRegistrar(...). The plugin only shipped the legacy RatexFlutterPluginRegisterWithRegistrar. Fix: add the C API header + a one-line shim that delegates to the legacy entry, so both name variants resolve to the same body.

Reproduction

flutter create --platforms=windows test_app && cd test_app
flutter pub add ratex_flutter
flutter build windows --debug

Before this PR fails with:

ratex_flutter_plugin.cpp(7,10): error C1083: Cannot open include file:
  'ratex_flutter/ratex_flutter_plugin.h': No such file or directory

After commit 1 alone, build progresses further then fails at:

generated_plugin_registrant.cc(10,10): error C1083: Cannot open include
  file: 'ratex_flutter/ratex_flutter_plugin_c_api.h': No such file or directory

After commit 2 the build succeeds.

Backwards compatibility

  • INTERFACE → PUBLIC: zero impact on consumers (PUBLIC is a strict CMake superset).
  • Legacy RatexFlutterPluginRegisterWithRegistrar entry remains in ratex_flutter_plugin.cpp unchanged. Any consumer still using the legacy name (older Flutter, manual registrant) sees no change — the new entry just calls into it.

Test plan

  • flutter build windows --debug succeeds on a fresh flutter create consumer (Flutter 3.41.9 stable / Win10)
  • flutter build apk --debug still succeeds (Android path untouched)
  • flutter build linux --debug not regressed (Linux CMakeLists untouched)
  • iOS / macOS — please verify in CI (those platform dirs untouched)

Versioning / CHANGELOG

Left to the maintainer's release process. No version bump or CHANGELOG entry in this PR.

- target_include_directories scope INTERFACE -> PUBLIC
- INTERFACE only exposes the dir to consumers, so the plugin target itself cannot resolve "ratex_flutter/ratex_flutter_plugin.h" and the Windows build fails with error C1083
- PUBLIC is a strict superset, so consumers see no behavioural change
- Adds ratex_flutter_plugin_c_api.{h,cpp} exporting RatexFlutterPluginCApiRegisterWithRegistrar, the name pattern Flutter auto-generated generated_plugin_registrant.cc has called since ~Flutter 2.10
- Without it the registrant fails to compile (missing header) and again at link time (missing symbol)
- New entry delegates to the existing RatexFlutterPluginRegisterWithRegistrar so both name variants resolve to the same body — no runtime behaviour change
- Hooks the new .cpp into PLUGIN_SOURCES
@erweixin

Copy link
Copy Markdown
Owner

thanks!

@erweixin
erweixin merged commit ea8c294 into erweixin:main May 16, 2026
3 checks passed
@TheMystery28
TheMystery28 deleted the fix/windows-plugin-build branch May 16, 2026 08:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants