You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment this project generates all its Rust code in a procedural macro, invoking bindgen (and thus llvm) during Rust compilation to parse C++ headers and convert to a Rust token stream.
Whilst it's rather awesome that it works, this has the following downsides:
We parse the C++ headers at least twice (once during Rust compilation and once during generating C++ bindings)
We need to do the work all over again for each time the Rust is compiled
Some say it's not the way procedural macros are supposed to behave
Since we have to run a tool to generate the C++ side of the bindings anyway, I intend to switch to a mode where:
That tool generates both Rust and C++ side of the bindings
On compilation, the include_cpp! macro (or future equivalent per Nicer syntax for include_cpp #42) simply expands to an include! macro invocation which pulls in the generated code.
This should be straightforward, although it's my intention that the filename of the generated code may want to depend upon the full parameters passed to the include_cpp! macro, to ensure there's lower risk of pulling in outdated generated code, so this may still need to be a small procedural macro.
The text was updated successfully, but these errors were encountered:
At the moment this project generates all its Rust code in a procedural macro, invoking bindgen (and thus llvm) during Rust compilation to parse C++ headers and convert to a Rust token stream.
Whilst it's rather awesome that it works, this has the following downsides:
Since we have to run a tool to generate the C++ side of the bindings anyway, I intend to switch to a mode where:
include_cpp!
macro (or future equivalent per Nicer syntax forinclude_cpp
#42) simply expands to aninclude!
macro invocation which pulls in the generated code.This should be straightforward, although it's my intention that the filename of the generated code may want to depend upon the full parameters passed to the
include_cpp!
macro, to ensure there's lower risk of pulling in outdated generated code, so this may still need to be a small procedural macro.The text was updated successfully, but these errors were encountered: