We are happy to announce the first public beta of the new clangml library. Clangml provides bindings for all versions of Clang, from 3.4 to 8.0.0.
In particular, Clangml allows OCaml program to use the Clang parser to parse C/C++ code and get an abstract syntax tree annotated with type information.
clangml can be installed via opam. Since the library relies on external dependencies, we suggest to use the depext plugin to install it together with the packages needed for your system:
opam depext -i clangml
This library is a complete rewritting of the previous clangml (clangml versions <4.0.0): the bindings now rely on automatically generated C stubs to libclang, with some extensions when libclang is incomplete.
Contrary to old clangml versions, the versions of clangml from 4.0.0 are independent from the version of the Clang library: any version of clangml from 4.0.0 can be built with any version of the Clang library in the supported interval. Currently, all versions of Clang, from 3.4 to 8.0.0, are supported.
I knew this thing had to be rewritten from scratch by a tremendous hacker.
I know this thing is a lot of hard work to write.
All my congratulations!
Thierry, feel free to point to this new project in the clangml github project.
Or, even put the old github project in a special branch and overwrite the master with your new project.
Also, if you now manage C++ (especially code with templates), this is a huge improvement compared
to the previous project.
Thanks for your interest, and for getting me involved in clangml!
We are still wondering whether we want to use github or gitlab.inria.fr for the next release, but at least if we choose gitlab.inria.fr, we should add a pointer to the new version in the README hosted by github.
There was no particular effort done until now to expose C++ AST, so the support is limited to what libclang exposes (in particular, yes, there are some functions to enumerate template arguments, and OCaml stubs for them are generated automatically).
Both of the topics (github vs gitlab, and better C++ support) should be solved soon, i.e. before the release: we are open to any advice and/or help for solving them!
Don’t use gitlab.inria.fr, ever, because external contributors cannot fork projects there, and thus cannot submit PRs/MRs. (This might change, but the fact that there exists people who think that this is a reasonable setting should give you pause.)
I like “gitlab” (the software) for being largely open-source, and there are hosting options for projects that are actually open, not just read-only throwaway research code. Gitlab.com is the most well-known (it uses the entreprise edition of Gitlab), Framagit is fine as well (it uses the open-source edition of Gitlab).
Summary: Gitlab has my personal preference for being open-source, but I strongly prefer either Github or non-inria Gitlabs over gitlab.inria.fr.
We chose gitlab.inria.fr, while being aware of its limitations: the arguments in favor of that choice were a combination of « not using GitHub » and « being corporate », but these arguments are obviously not as strong as « not being able for external contributors to make PR ». I am still hoping gitlab.inria.fr become more open, and I am still not sure about the right attitude to adopt about this (I am not sure that not using it is enough to make things change).
There is another thing to take into account: the vast majority of the OCaml community is on github.
While I don’t like the fact that github was bought by MS, I do like github’s interface, and I think it does accelerate and foster open-source collaborations.
I heard that the C binding is quite hard to use for C++ AST because many specific nodes are missing. Is it really the case? What about this OCaml binding?
There is still little support for C++, but it is plane to be fixed for clangml 4 release: for nodes that are missing in the C bindings, these OCaml bindings already directly bind to the Clang C++ API, so I hope to be able to overcome the C bindings limitations.