8 ms·

One of the most surprising things I learned about "clang" was how relatively poor the "libClang" capabilities are. I wanted to write a codegen tool that would

One of the most surprising things I learned about "clang" was how relatively poor the "libClang" capabilities are. I wanted to write a codegen tool that would auto-generate bindings for C++ code, and it turns out that "libTooling" is the only reasonable way to get access to the proper info you need from C++. Another alternative is "libClangSharp", from Tanner Gooding who works on C# at Microsoft. https://github.com/dotnet/ClangSharp https://github.com/dotnet/ClangSharp

HybridCurve 3y ago
This is another part of clang I've considered be almost, but not quite there yet. Some of the calls to the API are not very intuitive and they left too much out of libclang for it to be of anything but limited use. I am not a C++ guy, and it would be far too difficult for me to learn on a project such as this for my purpose so I had to use GCC instead. GCC has fairly good internals documentation (not just doxygen, thankfully) and the code is reasonably well annotated so it was't too difficult to work with.
mathisfun123 3y ago
Have you seen https://github.com/RosettaCommons/binder https://github.com/RosettaCommons/binder ? python aside, having gone down this rabbithole, and still not infrequently revisiting said rabbithole, I don't believe using *clang like this is a winning strategy. Because of the number of corner cases there are in eg C++17, you will end reimplementing effectively all of the "middle-end" (the parts that lower to llvm) for your target language. At that point you're not building bindings anymore but a whole-ass transpiler. Binder fails to be complete in this way. My current theory is to try "synthesize" bindings from the llvm ir (a much smaller representational surface). Problems abound here too (ABI). Alternatively there is https://cppyy.readthedocs.io/en/latest/ https://cppyy.readthedocs.io/en/latest/, which I don't completely understand yet.

HybridCurve 3y ago

This is another part of clang I've considered be almost, but not quite there yet. Some of the calls to the API are not very intuitive and they left too much out of libclang for it to be of anything but limited use. I am not a C++ guy, and it would be far too difficult for me to learn on a project such as this for my purpose so I had to use GCC instead. GCC has fairly good internals documentation (not just doxygen, thankfully) and the code is reasonably well annotated so it was't too difficult to work with.

mathisfun123 3y ago

Have you seen https://github.com/RosettaCommons/binder https://github.com/RosettaCommons/binder ? python aside, having gone down this rabbithole, and still not infrequently revisiting said rabbithole, I don't believe using *clang like this is a winning strategy. Because of the number of corner cases there are in eg C++17, you will end reimplementing effectively all of the "middle-end" (the parts that lower to llvm) for your target language. At that point you're not building bindings anymore but a whole-ass transpiler. Binder fails to be complete in this way. My current theory is to try "synthesize" bindings from the llvm ir (a much smaller representational surface). Problems abound here too (ABI). Alternatively there is https://cppyy.readthedocs.io/en/latest/ https://cppyy.readthedocs.io/en/latest/, which I don't completely understand yet.