On 02/04/14 23:00, James Buren wrote:
On Wednesday, 2 April 2014 at 15:49:18 UTC, Jacob Carlborg wrote:
Use a compiler that can already parse C, i.e. Clang.
Use a compiler that can handle those extensions, i.e. Clang.
I'm already wanting to reuse an existing parser or compiler frontend.
However, I have found myself frustrated and disappointed when I have
experimented with them.
Clang has an API that I find difficult to understand, so I can't really
say what may be an issue for it. But I have heard that it doesn't expose
any of the macros defined during the preprocessing phase.
Clang does expose macros, but not libclang, the C API. The solution is
to contribute to Clang and extend libclang with support for macros.
Both of these compilers seem to have issues which would limit what my
tool could do without bringing in an external tool to reinvent the wheel
just to make up for the absence of a critical feature.
But I have found several promising frontends that can provide the
information I need and are easy for me to understand.
Pycparser combined with a suitable preprocessor seems workable, but this
only works on ISO C99. The license is rather friendly, but is only
available in python.
Sparse, the tool used by the linux kernel for source code analysis,
provides a simple library API that exposes an entire C header or source
file into a simple to use AST. MIT licensed.
Cparser, a compiler using libfirm to generate code, provides an API I
find very easy to follow and use, but it is GPLv3 which does concern me
a bit.
You will get problems eventually if you don't use a proper front end
form a real compiler. Trust me, I've learned this the hard way. In the
end, it's the compiler that will determine what's legal and what's not.
So, in summary, please understand why I am wanting to redesign the
backend logic for generating a D interface. I find the existing
frontends most people use to be too limited for my purposes. My goal is
to want to convert as much of the C API as can be done automatically to
a D interface. The APIs for the major compilers most people think of do
not expose all the information I think is necessary for the future
expansion of a binding generator. If you have any better ideas, please
let me know.
Yes, contribute what's missing. I'm hopefully going to do that anyway,
with libclang, eventually.
--
/Jacob Carlborg
