More automated interfacing of D with C codebases

[Jacob Carlborg]

On 2012-10-15 13:51, CapitalLetterC wrote:
> This will be my first posting here, but I've been obsessed with D since
> before there was a D2 standard. Despite that rather long period of
> obsession, it's only just now that I've started seriously using D as I
> attempt to code-up some POC projects to demonstrate that the language is
> mature enough for serious development, or at least the kind of
> development we're doing, anyway.
>
> So, that out of the way, I suppose I should apologize in advance for
> what must amount to a pretty dumb question, since I truly couldn't have
> been the first to think of this: with regard to interfacing D with C
> libraries, why would we require a project like Deimos which ensures that
> each codebase is ported, almost entirely, by hand? Theoretically,
> shouldn't there be some kind of autotools-like method to establish
> something like, config.d.in which is then used via abstractions to
> properly configure the rest of the D wrapper? Obviously, D doesn't have
> a preprocessor, but couldn't one synthesize that with a series of
> judicious version() blocks? Then, whenever someone goes to build the
> application on their system, you'd have something to a series of
> autoconf-like tests to fill in the proper sections of of config.d.in and
> get out a config.d suitable for their system.
>
> I'm really sorry if there's some stupidly obvious reason this couldn't
> work and I'm just not seeing it, or if this is some n00b question you
> get all the time.

The header files need to be ported so D can find the declarations of the 
functions and types. There are a couple of tools that can do most of the 
work, but not completely. Macros are specially hard to port automatically.

https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg