More automated interfacing of D with C codebases

[CapitalLetterC]

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.