DStep is a tool for translating C and Objective-C headers to D modules. It uses libclang for lexing/parsing and AST traversal. This means it handles everything that Clang itself can handle, although this doesn't mean it will correctly translate everything.

I would consider this release alpha or beta. I'm releasing this now in hope I get some feedback on what language features the tool can't handle.

The tool is available at github:
https://github.com/jacob-carlborg/dstep

Binaries are available for Mac OS X and Ubuntu 11.10 32bit:
https://github.com/jacob-carlborg/dstep/downloads

Unfortunately I haven't been able to successfully compile it on Windows due to Optlink not cooperating. I'll most likely provide Linux binaries with better compatibility later.

Build instructions are available at github.

Usage:

dstep <input-file.h> -o output_file.d

For Objective-C

dstep <input-file.h> -o output_file.d -ObjC

Tests:

DStep uses Cucumber and Aruba (Ruby tools) to run its tests. It will basically run the tool on all *.h files in the "test_files" directory and compare the results to the corresponding *.d files.

Known issues/missing functionality:

* Multiple input files
* Framework as input file
* Add module declaration
* Option for specifying before and after code
* Option for specifying package
* Windows support

C:
    * Self includes
    * Out of order typedefs of structs
    * Bitfields
    * Non-standard extensions
    * Preprocessor
    * Arrays with no size marked as "extern".

Objective-C:
    * Protocols
    * Properties
    * Blocks
    * Categories
    * Actions
    * Outlets
    * Selectors

This is basically what's on the todo list:

https://raw.github.com/jacob-carlborg/dstep/master/todo.taskpaper

There's no point in reporting issues which are listed above.

-- 
/Jacob Carlborg

On 7/7/2012 7:47 AM, Jacob Carlborg wrote:
> DStep is a tool for translating C and Objective-C headers to D modules. It uses
> libclang for lexing/parsing and AST traversal. This means it handles everything
> that Clang itself can handle, although this doesn't mean it will correctly
> translate everything.
>
> I would consider this release alpha or beta. I'm releasing this now in hope I
> get some feedback on what language features the tool can't handle.

I think this is potentially a big deal.

If it can be made complete enough, I'd like to add support into D for it, so you could do things like:

    import "stdio.h";

and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file.

Some issues:

1. Passing macro definitions to Dstep

2. The name "Dstep" has no obvious relationship to what it does.

3. The -o flag is not necessary. Just "do the right thing" when you see the filename extension.


In fact, we could make it a general facility, where if D sees:

    import "filename.ext";

that it fork/exec's the program:

    ext_to_D filename.ext tmpfile.d

and them imports tmpfile.d.

Wow at long last!

On Saturday, 7 July 2012 at 21:20:53 UTC, Walter Bright wrote:
> On 7/7/2012 7:47 AM, Jacob Carlborg wrote:
>> DStep is a tool for translating C and Objective-C headers to D modules. It uses
>> libclang for lexing/parsing and AST traversal. This means it handles everything
>> that Clang itself can handle, although this doesn't mean it will correctly
>> translate everything.
>>
>> I would consider this release alpha or beta. I'm releasing this now in hope I
>> get some feedback on what language features the tool can't handle.
>
> I think this is potentially a big deal.
>
> If it can be made complete enough, I'd like to add support into D for it, so you could do things like:
>
>     import "stdio.h";
>
> and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file.
>
> Some issues:
>
> 1. Passing macro definitions to Dstep
>
> 2. The name "Dstep" has no obvious relationship to what it does.
>
> 3. The -o flag is not necessary. Just "do the right thing" when you see the filename extension.
>
>
> In fact, we could make it a general facility, where if D sees:
>
>     import "filename.ext";
>
> that it fork/exec's the program:
>
>     ext_to_D filename.ext tmpfile.d
>
> and them imports tmpfile.d.

On 07/07/12 23:20, Walter Bright wrote:
> In fact, we could make it a general facility, where if D sees:
> 
>     import "filename.ext";
> 
> that it fork/exec's the program:
> 
>     ext_to_D filename.ext tmpfile.d
> 
> and them imports tmpfile.d.

   import extern (C) "stdio.h";

which execs

   dimport_C "stdio.h"

which returns a filename of a D module, which is then imported.

This way the importer can cache the result and doesn't need to regenerate the D module until "stdio.h" or any dependency changes.


artur

On 7/7/12 5:20 PM, Walter Bright wrote:
> In fact, we could make it a general facility, where if D sees:
>
> import "filename.ext";
>
> that it fork/exec's the program:
>
> ext_to_D filename.ext tmpfile.d
>
> and them imports tmpfile.d.

(Aside) This has an obvious security risk.

Andrei

On 7/7/12 10:47 AM, Jacob Carlborg wrote:
> DStep is a tool for translating C and Objective-C headers to D modules.

Awesome! On reddit:

http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/


Andrei

On 7/7/2012 7:59 PM, Andrei Alexandrescu wrote:
> On 7/7/12 5:20 PM, Walter Bright wrote:
>> In fact, we could make it a general facility, where if D sees:
>>
>> import "filename.ext";
>>
>> that it fork/exec's the program:
>>
>> ext_to_D filename.ext tmpfile.d
>>
>> and them imports tmpfile.d.
>
> (Aside) This has an obvious security risk.

Yup. It's similar to the import arbitrary file as string feature. We can leave it disabled unless -J is used.

On 7/7/2012 8:40 PM, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/


Gotta change the name:


http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/c5az51y

On Sunday, 8 July 2012 at 08:36:34 UTC, Walter Bright wrote:
> On 7/7/2012 8:40 PM, Andrei Alexandrescu wrote:
>> http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/
>
>
> Gotta change the name:
>
>
> http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/c5az51y

Just make it drop when you're done translating the file.

On 2012-07-07 23:20, Walter Bright wrote:

> I think this is potentially a big deal.
>
> If it can be made complete enough, I'd like to add support into D for
> it, so you could do things like:
>
>      import "stdio.h";
>
> and the D compile would fork/exec Dstep, generate the corresponding .d
> file, and import the .d file.

How is this going to work, is it going to be an optional feature? I mean, this will add DStep (D and Clang) as dependencies to DMD.

DStep is built to be used as a library, I can easily create a C API which can be used directly by DMD. No need for creating a new process. I can also make DStep give back the translate D code, no need for creating temporarily D files.

BTW, how would you indicate that the header file is an Objective-C file? Since both C and Objective-C uses the same extension for header files, this is required by Clang, otherwise it will treat the file as a C file.

> Some issues:
>
> 1. Passing macro definitions to Dstep

Yeah, this will be the hardest. The main problem now is that libclang (the stable C API) doesn't have an API for handling macros.

> 2. The name "Dstep" has no obvious relationship to what it does.

No it does not, but I'm tired of trying to come up with cleaver names for tools and libraries.

Here's the story behind the name for those who are interested:

DStep started out as another project, as a D-Objective-C bridge:

http://dsource.org/projects/dstep

In that project I had a tool for converting C/Objective-c headers to D modules. This tool was a Ruby script based on BridgeSupport. This is a complete rewrite of that tool. The whole project was called DStep and the name fit among other Objective-C related names like NeXTSTEP, OpenStep and GNUStep.

> 3. The -o flag is not necessary. Just "do the right thing" when you see
> the filename extension.

That can be easily fixed.

> In fact, we could make it a general facility, where if D sees:
>
>      import "filename.ext";
>
> that it fork/exec's the program:
>
>      ext_to_D filename.ext tmpfile.d
>
> and them imports tmpfile.d.


-- 
/Jacob Carlborg