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