migration: test and devise a migration path for importers of sbinet/go-clang

[sbinet]

before announcing github.com/go-clang and freezing sbinet/go-clang, we should probably test and devise a migration path for the importers of sbinet/go-clang:

https://godoc.org/github.com/sbinet/go-clang?importers

ie:

• https://github.com/google/navc
• https://github.com/quarnster/completion/tree/master/clang/libclang

[useche]

I'm the owner of https://github.com/google/navc. FWIW, I made the change today to v3.7 clang.

[zimmski]

@sbinet the changes for the switch to the go-clang version repository is here google/navc@1eaff08

[zimmski]

General question: Do we really need a migration script? It is btw not simply replacing the import path. The user has to choose which Clang version is in use, and then he has to replace a lot of API calls. So, what should we do?

[FrankReh]

For the record, when I switched over, I found it a trivial manual process.
The compiler told me when anything wasn't right. I remember function names
not always being the easiest to figure out right away, but I never thought
there needs to be a script that can do this for me - silly me.

Since this is going to the design thread. Was wondering if the general
design of get had been written up as a short page somewhere? The
gen/bootstrap part had me very confused when I looked at it but when v3.9
just works, I don't need to know how it was gen'ed anyway. I had not found
the basic thread to follow. Maybe it's already there and if I were to look
again now, I'ld come across it. Anyway, I'm adverse to ask for more
because this glue between go and the clang library is already awesome.

I do realize you use go-clang to build go-clang, hence the bootstrap
repository. That in and of itself is so cool and now go is used to build
go. Hah.

On Tue, Sep 13, 2016 at 12:03 PM, Markus Zimmermann <
[email protected]> wrote:

General question: Do we really need a migration script? It is btw not
simply replacing the import path. The user has to choose which Clang
version is in use, and then he has to replace a lot of API calls. So, what
should we do?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFdfOCYkcn_u3jC3IIfUmknq73lWcSD8ks5qpsligaJpZM4Gsi00
.

[zimmski]

Sounds to me that it would be helpful to add a small script. I also think that it is good enough to just always switch to go-clang/v3.4 because the original go-clang repository is 3.4.

I guess the big picture is described in the second paragraph of https://github.com/go-clang/gen#how-to-contribute Does this answer your questions? Basically, a normal user should only need the version repositories like v3.4 and not the gen repository. gen and bootstrap are for generating the bindings. If you have an idea how we can make this more clear I am all ears :-)