(Oh My) Gentool 0.3.0 released

[Gavin Ray]

On Monday, 10 May 2021 at 07:11:26 UTC, evilrat wrote:
> 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.

Yeah, this is true. I actually ran into this issue already -- you 
have extreme devspeed + flexibility with Python but you're 
essentially "blind" as to the API and it's a lot of 
trial-and-error if it's not a very trivial C++ library.

I think the end goal of being able to provide some way to easily 
hook into the codegen pipeline so that users can make tweaks 
easily & contribute them back, or customize it for personal use 
is probably more important than the "how". This was just the best 
"how" I could come up with at the time, hah.

> 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.

What about adding `cling` for interpreted JIT C++ without 
handicaps?

https://blog.llvm.org/posts/2021-03-25-cling-beyond-just-interpreting-cpp/

This would let both you and users rapidly develop/iterate-on the 
codegen part without needing to recompile the entire solution.

The main application hosts the `cling` process, and you don't do 
anything except bring the codegen bits in as JIT-interpreted 
files. It's not like performance is critical here, you know?😅

The end result is that you (or anyone else) can modify the actual 
codegen code, and re-run the compiled binary without needing to 
do anything else. `cling` will take care of acting as the engine 
to sort out `#include`'s, template instatiations, global context, 
etc.

I dunno, I don't really know that much about this area at all. So 
there's also a good chance this idea couldn't/wouldn't work, and 
is not a good one -- but in my naive head it sounds good!

> 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.

Yeah, so the issue there was that `cppyy` needs dynamic libs to 
be able to work.
LibTooling hilariously enough can't even be compiled as a dynamic 
lib on Windows, since there's a limit of ~65,000 exported visible 
symbols and `LINK.exe` will error.

So between wanting the user to have a fairly recent, 
self-compiled version of LLVM, and not working on Windows at all, 
the easiest thing seemed to be to ask "Hey, just do `docker run` 
and that'll run an Ubuntu image with LLVM 13 built with 
LLVM_ENABLE_SHARED_LIBS and Python 3 and all of this set up for 
you."

Not ideal but also I think maybe the only way to make the `cppyy` 
thing work haha.