Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.

I added a new pragma, include, that handles everything. Use like this:

// foo.h
void foo ();

// main.d

module main;

pragma(include, "foo.h");

void main ()
{
    foo();
}

DMD: https://github.com/jacob-carlborg/dmd/tree/dstep
DStep: https://github.com/jacob-carlborg/dstep/tree/c_api

-- 
/Jacob Carlborg

On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
> Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.
>

awesome! :-)

On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
> Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.

While this a relatively common request, I don't think such stuff belongs to compiler. It creates extra mandatory dependencies while providing little advantage over doing this as part of a build system.

So far I am perfectly satisfied with invoking dstep from a Makefile.

On Tue, Jul 16, 2013 at 8:05 AM, Dicebot <public@dicebot.lv> wrote:

> On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
>
>> Made a proof of concept to automatically parse, translate and import C header files in D using DStep. DMD is linked against DStep and does not start new process to make the translation.
>>
>
> While this a relatively common request, I don't think such stuff belongs to compiler. It creates extra mandatory dependencies while providing little advantage over doing this as part of a build system.
>
> So far I am perfectly satisfied with invoking dstep from a Makefile.
>

I agree that this stuff doesn't belong to compiler, however Makefiles suck (not even portable) and build systems should be avoided whenever a more integrated solution exist.

So how about a library solution instead, which doesn't require compiler change:

----
import parse_c_header_importer;
mixin(parse_c_header(import("foo.h")));
void main () { foo();}
----

There are several options:

A)
mixin(parse_c_header(import("foo.h"))); => defines D symbols for everything
in foo.h (excluding things included by it)

B)
mixin(parse_c_header(import("foo.h"),recursive)); => same, but recursively
(probably not very useful, but could be useful if we instead used .i swig
interface files.

C)
The least wasteful:
void foo();
int bar();
mixin(parse_c_header(import("foo.h"),foo,bar));
=> only defines symbols provided

(I've proposed this syntax in an earlier thread)

On 7/16/2013 8:49 PM, Timothee Cour wrote:
> So how about a library solution instead, which doesn't require compiler change:

While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.

On Tue, Jul 16, 2013 at 9:14 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 7/16/2013 8:49 PM, Timothee Cour wrote:
>
>> So how about a library solution instead, which doesn't require compiler change:
>>
>
> While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
>

it would trivially, with CTFE exec.
Yet another enabling use case.

On Wednesday, 17 July 2013 at 03:49:32 UTC, Timothee Cour wrote:
> I agree that this stuff doesn't belong to compiler, however Makefiles suck

Here I may agree (for a different reasons probably)

> and build systems should be avoided  whenever a more
> integrated solution exist.

..but not here. Integrated solutions suck even harder than Makefiles.

On Wednesday, 17 July 2013 at 04:32:12 UTC, Timothee Cour wrote:
> On Tue, Jul 16, 2013 at 9:14 PM, Walter Bright
> <newshound2@digitalmars.com>wrote:
>
>> On 7/16/2013 8:49 PM, Timothee Cour wrote:
>>
>>> So how about a library solution instead, which doesn't require compiler
>>> change:
>>>
>>
>> While semantically a great idea, technically I don't think CTFE is up to
>> implementing a C front end yet.
>>
>
> it would trivially, with CTFE exec.
> Yet another enabling use case.

Just because a bad solution is faster to implement doesn't make it good.

On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:
> On 7/16/2013 8:49 PM, Timothee Cour wrote:
>> So how about a library solution instead, which doesn't require compiler change:
>
> While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.

This is the right path. We don't need the full front end, do we ?

On Tue, Jul 16, 2013 at 10:04 PM, deadalnix <deadalnix@gmail.com> wrote:

> On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:
>
>> On 7/16/2013 8:49 PM, Timothee Cour wrote:
>>
>>> So how about a library solution instead, which doesn't require compiler change:
>>>
>>
>> While semantically a great idea, technically I don't think CTFE is up to implementing a C front end yet.
>>
>
> This is the right path. We don't need the full front end, do we ?
>

what's a non-full C front end? If it's not a real C front end it's gonna break with certain macros etc. Not good.

I see no point in re-implementing a C front end when we can simply use an existing one to do the job (eg clang). This would also allow to parse C++ just as well.