[WIP] generate bindings using libclang #642
Conversation
|
|
||
| import scalanative.native._ | ||
|
|
||
| #define EXTERN_FUNCTION0(symbol, id, tpe) @name(#symbol) def id(): tpe = extern; |
There was a problem hiding this comment.
A new type of Scala macro ;)
| struct bindgen_context *ctx = data; | ||
|
|
||
| CXSourceLocation location = clang_getCursorLocation(cursor); | ||
| if (!clang_Location_isFromMainFile(location)) |
| |@extern | ||
| |object Test { | ||
| | object color { | ||
| | val RED = 1 |
There was a problem hiding this comment.
maybe @inline final val ?
| extern; | ||
|
|
||
| @name("scalanative_clang_getCursorKind") | ||
| def getCursorKind(`*cursor`: CXCursor): CXCursorKind = extern; |
There was a problem hiding this comment.
hum this *cursor looks suspicious.
There was a problem hiding this comment.
Yes, this is a relic of using C preprocessor to generate the Scala code.
|
|
||
| Binding generation for now is experimental. The goal is to first use it | ||
| internally to generate bindings for C's stdlib and later make it | ||
| available via scala.meta macros and sbt tasks. |
There was a problem hiding this comment.
I would vote for code generation here. The less powerful technique that works well with IDEs
There was a problem hiding this comment.
IDE support is a blocker here, if scala.meta macros don't work well enough we might have to use code generation instead.
|
Really cool! Nice work. I can help on the sbt front ;-). |
jonas
force-pushed
the
bindgen
branch
3 times, most recently
from
9d1d4da to
f2f6e79
Compare
|
The main problem right now is that xcode includes the libclang dynlib but not the libclang header files. |
jonas
force-pushed
the
bindgen
branch
2 times, most recently
from
004912c to
3ab0c59
Compare
|
Achievement unlocked 🎉 CI passes |
.travis.yml
Outdated
| - brew install jq | ||
| - brew install re2 | ||
| - brew install [email protected] | ||
| env: PATH="$PATH:/usr/local/opt/[email protected]/bin" |
There was a problem hiding this comment.
To keep the macOS build on the same version, however, we could also change it so CI builds for oldest and newest supported LLVM version.
|
Amazing progress @jonas! I'm going to have a deeper look at the code itself as soon as 0.2 is shipped. |
jonas
force-pushed
the
bindgen
branch
2 times, most recently
from
8545f12 to
2d6af88
Compare
densh
changed the title
Make sure we pick the version of llvm-config which matches the discovered clang binary. Currently Scala Native does not use LLVM include and libraries however this will be important for bindgen and other tooling.
This is an interesting problem. I work on a binding tool for D [1] myself using libclang as well. When header files start to use #ifdef _WIN32
#include <windows.h>
DWORD foo();
#else
int foo();
#endifThe above code would generate different bindings on different platforms. Trying to generate bindings for the Windows branch on a Posix platform wouldn't work because I would also say it depends on how the bindings are used/generated. If the bindings are to be generated with an external tool and placed in a source repository you will have the problem mentioned above. The advantage of this approach is that it's possible (or at least simpler) to create wrappers on top of the bindings, to make the API nicer for the host language. But, if the bindings are generated on the fly by the compiler or a build tool the above problem doesn't matter since you can only interface with the API that is provided on the current platform anyway, making platform dependent bindings not an issue. This is kind of how Swift interfaces with C and Objective-C. |
Imports the libclang wrapper from scala-native/scala-native#642 as well as the build setup to compile it. Test bindgen against the existing test files in a separate project.
|
It seems like current state of this PR is a bit premature to be included upstream. Especially considering that we're planning to do a major overhaul of the interop layer in 0.4 series. Additionally, the binding generation tool can happily leave outside of the main repo in its own subproject and including it into the main repo might aggravate our build time and CI issues we've been having recently. I'm closing this PR for now, we can continue discussion on going forward with this on gitter. |
|
👍 |
4 participants
This is still early stage, but it would be great to have some feedback regarding what to focus on at this point and ease the way to have it integrated. For now it is focused on internal usage and a good use case will be to help complete #104. However, for this to happen there are some things to figure out such as how to sort the read C types to make them stable across systems, whether to use white- or black-listing to "weed" out non-POSIX/standard types etc.
Some initial thoughts can be found in docs/contrib/bindgen.rst
And a dummy test parsing unit-tests/src/main/resources/bindgen/test.h is in the BindgenSuite.
References: #154
CC: @frgomes