Doxygen XML Generation Bug and Bootstrap Failure

[asctime]

Thank you for your work and appears promising. I will submit multiple issues.

First issue is the API wrapper construction.
The reliance on a Doxygen XML parsing pipeline to drive wrapper generation introduces a brittle, out-of-band build dependency. This frequently results in silent build-time starvation, producing hollow binaries that compile cleanly but export zero actual runtime symbols. While generating bindings from documentation artifacts may have historically served as a legacy workaround to avoid choking SWIG on the massive preprocessor footprint and conditional blocks (#ifdefs) of the wxWidgets headers, this approach is completely obsolete. These macro nuances can be trivially amended and neutralized directly at the toolchain layer using standard compiler design patterns. 

Rather than maintaining a fragile pipeline meant for human-readable webpage documentation, the project should migrate to one of the following production-grade alternatives: 

1. Direct SWIG Header Parsing with Directive Overrides:** Modern SWIG is fully capable of parsing raw C++ headers directly. The platform-specific nuances and complex GUI macros can be stripped out or mocked seamlessly by passing a dedicated, global macro definition interface directly to SWIG’s internal preprocessor before it performs its code-generation pass.
2. Clang AST Metadata Extraction:** If automated code generation remains a core design goal, the system should leverage a real compiler front-end like CastXML or a lightweight Clang-based AST parsing script. This resolves all headers, macros, and platform conditionals perfectly at the abstract syntax tree layer, outputting a flawless semantic map of the API that SWIG can reliably consume.

--> Documentation tools should not drive compiler <-- wrappers; a modern, frontend-driven toolchain would drastically simplify the codebase and permanently eliminate these hollow wrapper loops.

[mcorino]

Thank you for your comments.
For the time being I converted this issue to a discussion thread so people can comment on your ideas.
Whenever people start committing PR's for these ideas we can add task issues whenever required.

Your ideas are interesting but I wonder if you have already tried to generate wxRuby3 SWIG wrappers directly from wxWidgets library headers (or the documentation headers)?

Some of the advantages I see in using the an indirect approach using the documentation headers/doxygen XML is the fact that it cuts down on unnecessary wrapper generation as the wxWidgets headers declare/implement a LOT more methods than are documented for public use. Also the documentation provides meta information concerning platform support for several methods that can easily be extracted and used for platform specific code generation which would otherwise be more difficult to extract from the regular library headers.

[asctime]

No problem, I see this as both a bug and a discussion so either is fine. "headers declare/implement a LOT more methods than are documented for public use" I can understand this logic, but reverses the API paradigm to docs->API which is fundamentally backwards, assumes accurate documentation (not always the case), is unconventional (rarely used approach) so a bit of a head-scratcher for outside development or porting and, most importantly, fundamentally brittle.

At very least include version-locked swig files in source distribution which your custom process generates, as opposed to expecting everyone else to duplicate your custom approach from scratch.

I am considering forking the version I require for my uses and seeing what can be done in terms of correcting this.

UPDATE:
Running with corrections posted in gist https://gist.github.com/asctime/290355e24bad080d2955ed6730d260d6
NOTES:
Requires settings:
set MSYSTEM_PREFIX=/MSYS2/mingw64
set RI_DEVKIT=/MSYS2/mingw64

Then running:
sed -i 's/wxRuby_GetSwigTypeForClassName(class_name)/wxRuby_GetSwigTypeForClassName((const char*)class_name.mb_str())/g' ext/wxruby3/src/*.cpp
bundle exec rake configure WXWIN=[Full path, backslashed..]/MSYS2/mingw64 WXXML=[Full path, backslashed..]/mingw-w64-wxwidgets3.2/src/wxWidgets-3.2.8.1/docs/doxygen/out/xml
bundle exec rake build

No "rake install", the custom .pkg streaming is likewise brittle, no-op for my tools (why?), hand-copied .so files appropriate location
Old version doxygen possibly required (ended up with cywin-msys2 doxygen 1.8.14 (working)

"MSYSTEM_PREFIX" is incorrect. MSYS2 is an Arch-community driven Linux-servicing derivative. It is not MinGW.