Permalink
Reply
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
cppyyin Python (which usescling) 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:
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.
