On Monday, 15 October 2012 at 12:54:51 UTC, Jacob Carlborg wrote:
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
Actually, I understand perfectly well why the headers need to be
ported to D code, what I was more wondering is if anybody knew of
or had ever tried to use some kind of build system to automate
the process to the greatest extent possible. So, for example, as
a result of the configuration process certain features may be
implicitly or explicitly enabled/disabled, without probing the
individual user's configuration, you wouldn't know that, so how
does one maximize portability, in that case? If you simply go to
support the maximal set of features, you may wind up with a bunch
of codepaths that go nowhere, likewise, if you choose only to
support the minimal set of functionality, you may not wind up
with code that's not useful to anyone, yourself included.
Granted, I hadn't thought of the difficulty in porting things
like macros, but I'd imagine that, in the absolute worst case,
you could synthesize their behavior with templates.
But there are all sorts of issues in that same vein, like how
certain structs get put together, what types are aliased with
what, etc. That's why I was wondering if you could handle this
analogously to how C does, with a config file that gets setup by
a kind of configuration system.
