More automated interfacing of D with C codebases

CapitalLetterC zarathustra.zoroaster at gmail.com
Mon Oct 15 04:51:19 PDT 2012


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.


More information about the Digitalmars-d-learn mailing list