renderPragma, cleanup

This commit is contained in:
Ganesh Viswanathan 2020-07-15 11:33:26 -05:00
commit e61dc54a89
3 changed files with 294 additions and 263 deletions

View file

@ -47,10 +47,12 @@ https://github.com/nimterop/nimterop/compare/v0.5.9...v0.6.5
- All `cDefine()`, `cIncludeDir()` and `cCompile()` calls now forward relevant pragmas into the generated wrapper further enabling standalone wrappers. [#239][i239]
- Added `cPassC()` and `cPassL()` to forward C/C++ compilation pragmas into the generated wrapper. (since v0.6.5)
- Added `cPassC()` and `cPassL()` to forward C/C++ compilation pragmas into the generated wrapper. These should be used in place of `{.passC.}` and `{.passL.}` and need to be called before `cImport()` to take effect. (since v0.6.5)
- Added `--compile`, `--passC` and `--passL` flags to `toast` to enable the previous two improvements. (since v0.6.5)
- Added `renderPragma()` to create pragmas inline in case `cImport()` is not being used. (since v0.6.5)
### Other improvements
- Generated wrappers no longer depend on nimterop being present - no more `import nimterop/types`. Supporting code is directly included in the wrapper output and only when required. E.g. enum macro is only included if wrapper contains enums. [#125][i125] (since v0.6.1)
@ -61,6 +63,7 @@ https://github.com/nimterop/nimterop/compare/v0.5.9...v0.6.5
- `cDefine()` can now accept a `seq[string]` of values. (since v0.6.5)
## Version 0.5.0
This release introduces a new backend for wrapper generation dubbed `ast2` that leverages the Nim compiler AST and renderer. The new design simplifies feature development and already includes all the functionality of the legacy algorithm plus fixes for several open issues.