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
