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