use go-generate to generate most of the go-clang code

[sbinet]

it should be possible to use go-clang (or python-cindex) to generate most of the go-clang code, starting from a parsed representation of a given CIndex API version.

This would tremendously reduce the maintenance load of keeping up with the LLVM/CIndex API churn.

Ideally, just running go generate in go-clang repository would generate the whole set of stubs (and possibly the complete bindings?) for each CIndex version.

[zimmski]

So I hacked something small together https://github.com/zimmski/go-clang-phoenix I just did the basics and added generation for enums with "Kind" in their name. Example
https://github.com/zimmski/go-clang-phoenix/blob/master/typekind_gen.go
original version https://github.com/sbinet/go-clang/blob/master/typekind.go There is still a LOT to do and refactor.

As you can see I used "Type_" instead of "TK_" as prefix. Which is in my opinion more intuitive. I am just asking if you are OK with this? Since a rewrite can be seen as completely new version.

Also I will occasionally work on this rewrite over the next weeks, I cannot focus completely on it since I need to work on other things too. I would be glad if you can give me some feedback.

[sbinet]

that's a really great start!

the TK_ -> Type_ renaming is fine. (we could even go one step further and make golint happy by dropping the _...)

[zimmski]

I put that in as a TODO. A friend of mine will support me with this work so I hope we will get this done in one or two hacking sessions.

Btw. generating the code makes it also possible to adapt the comments for Go see https://godoc.org/github.com/zimmski/go-clang-phoenix

[zimmski]

@sbinet: We are in the process of finishing the rewrite. Please take a look https://github.com/zimmski/go-clang-phoenix There are some small API problems left but nothing frightening. Most of the open issues are refactoring the code and transforming it into a generic solution. Another issue left is writing how to test and release new versions. I will demonstrate using the rewrite repository.
So, what do you think?

[sbinet]

sounds good.

perhaps it would make sense to create a github.com/go-clang organization and:

• put the current sbinet/go-clang repository as github.com/go-clang/bootstrap
• put the code using go-clang/bootstrap as github.com/go-clang/clang/cmd/gen-clang
• put the result as github.com/go-clang/clang

ideally, the result could just be (re-)generated via go generate

what do you think?

(names are all tentative)

[zimmski]

I think it makes sense to create a new organization but naming the repositories could be tricky. Right now there are some heuristics to figure out how to generate the API and some manually written functions and types. I do not think that this will go away and it can vary between Clang versions. The current plan is to refactor everything so that we can have a "go-clang-generate" main function with just the version specific heuristics. Everything else is in a general package (to convert C APIs to Go) and in a Clang specific package (general heuristics for Clang).

Also, I do not think that go generate is needed since there is nothing to annotate. It would currently just say //go:generate go-clang-generate.

[sbinet]

ok. let's close this issue and move the discussion over at go-clang/design#1