(Oh My) Gentool 0.3.0 released

[evilrat]

On Sunday, 9 May 2021 at 19:35:52 UTC, Gavin Ray wrote:
>
> **However, I had an idea which I haven't seen tried yet, and 
> have been prototyping:**
> - Using `cppyy` in Python (which uses `cling`) for runtime 
> bindings to C++ and ability to write raw C++ code in Python 
> strings and JIT compile it.
>
> - Allow users to write "drivers"/"clients" in Python which do 
> the codegen. Since Python isn't compiled, this means you can 
> realtime tweak and visualize your output much faster than 
> manually recompiling a C++ based LibTooling application.
>
> I am thinking of some kind of API where you can declare rules 
> using annotations for AST nodes above functions for handling 
> them. Something like:
> ```py
> class DCodegen:
>     # "t" here is a LibTooling AST node and we can use all of 
> Clang/LibTooling's AST API
>     @rule(lambda t: t.is_pointer() or t.is_reference() and \
>                     t.pointee().is_record_indirection())
>     def input(cls, t, args):
>         return f"{{interm}} = &{c_util.struct_cast(t, 
> '{inp}')};"
>
>     @rule(lambda t: t.is_pointer() or t.is_reference())
>     def input(cls, t, args):
>         raise ValueError("unsupported input pointer/reference 
> type {}".format(t))
> ```
>
> This would allow people to contribute or tweak the codegen to 
> their liking very rapidly.

It's all libclang under the hood though. Never looked at the 
sources of cppyy or cling, but very likely this works for them 
because of libs such as pybind11 that wraps C++ stuff in C++, 
while the other tools trying to rely on C API(very limited) or 
keep fighting with C++ API, you've already seen that all that 
tools from that list except gentool is using C API and what 
capabilities each provides.

Can't say I hate that idea, but it has same issues as SWIG, 
writing any non trivial rule becomes next to impossible as there 
is practically zero examples and very poor documentation, the 
whole process becomes trial and error marathon without chance to 
win, and it is basically write-only code that is as worse as C++ 
templates. But it is definitely better than SWIG in that regard 
as you can get type and functions information using dir() and 
help() and your trusty IDE with debugger.

My current plan though is to provide predefined pre-generate and 
post-generate rules that is applied declaratively in project 
config,
for example
   `ignoreDecls *::new[]`
that will ignore all new operator overloads in any namespace, or 
one of any other existing rules that deals with specific 
patterns, and at some point later allow users to write their own 
rules like you described.
After all this is binding/translator tool, not an universal 
one-for-all code generator.

> For distribution, it could be done in an Ubuntu Docker 
> container that comes with LLVM and Python in it, and the 
> scripts, then mapped to local filesystem for read access + also 
> if you want to edit the `DCodegen` script or supply your own 
> Python file as the driver.
>

No way, Docker is too heavy and not very user friendly or even CI 
friendly. It is ok to have builds optionally packed in container, 
but not as the only way to distribute. It might work for 
cppyy/cling because they rely on specific dynamic library 
properties or fork process on *NIX that is not there on Windows.