Help for .h to D pain?

Nov 12, 2010

jfd

Nov 12, 2010

div0

Nov 12, 2010

div0

Nov 12, 2010

jfd

Nov 13, 2010

Matthias Pleh

I was trying to translate Apache module include files to D, but it soon leads to a labyrinth of tangled nested #includes and #define and typedef's. The tools, `dmc -c -e -l', htod, etc. immediately choked. It is getting really, really,... time consuming, and the words "man years" flashes before my eyes :O... I'm beginning to see why C++ supports the .h's... after years of knocking it... :( There's gotta be a easier way... Help me!... DMC is spewing out errors: ----------------------------------------- $ dmc -I. -c httpd.h -e -l #define __STDC_IEC_559__ ^ features.h(327) : Preprocessor error: macro '__STDC_IEC_559__' can't be #undef'd or #define'd #define __STDC_IEC_559_COMPLEX__ ^ features.h(328) : Preprocessor error: macro '__STDC_IEC_559_COMPLEX__' can't be #undef'd or #define'd typedef __signed__ char ^ asm-generic/int-ll64.h(19) : Error: '=', ';' or ',' expected typedef __signed__ short __s16; ^ asm-generic/int-ll64.h(22) : Error: illegal combination of types typedef __signed__ int __s32; ^ asm-generic/int-ll64.h(25) : Error: illegal combination of types Fatal error: too many errors --- errorlevel 1 ----------------------------------------- HTOD too: ----------------------------------------- $ htod httpd.h Fatal error: unable to open input file 'features.h' $ htod -I. httpd.h #define __STDC_IEC_559__ 1 ^ features.h(327) : Preprocessor error: macro '__STDC_IEC_559__' can't be #undef'd or #define'd #define __STDC_IEC_559_COMPLEX__ 1 ^ features.h(328) : Preprocessor error: macro '__STDC_IEC_559_COMPLEX__' can't be #undef'd or #define'd Fatal error: unable to open input file 'stddef.h' ----------------------------------------- And what tool is there on Linux? Hey, here's a crazy idea: Why not support #include "x.h"? Now that's "seamless"! That's ONLY, and I emphasize ONLY (before someone goes nuts with it), for supporting existing C libraries, not for general D programming. Internally, it would import everything in .h that it reads as `extern(C)' objects for D, or something like that. LLVM has C compiler, right? Why not borrow its header file parser (if license allows)? BTW, LDC and clang LLVM C compiler both compile to LLVM, so they should be able to read each other's stuff, right? That maybe a discussion more for the LDC forums, but it also would involve D language change. I'm okay with a "standard tool" instead of new "language feature", if that tool makes it EEEASY..., and works "flawlessly" and "seamlessly" on Linux, Windows, Mac, etc. Hey, maybe that's beginning to sound like a big project in itself, close to a full C compiler... :) Help, anyone? Thank you.

On 12/11/2010 04:01, jfd wrote: > > Help, anyone? Thank you. The easiest way is to simply compile a one liner C module. Then you get all the necessary stuff included and all the irritating macros stripped out and converted to what they are actually supposed to be. You can then probably run htod successfully; even if not it's much easier converting the code by hand. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk

On 12/11/2010 13:21, div0 wrote: > On 12/11/2010 04:01, jfd wrote: >> >> Help, anyone? Thank you. > > The easiest way is to simply compile a one liner C module. > Then you get all the necessary stuff included and all the irritating > macros stripped out and converted to what they are actually supposed to > be. You can then probably run htod successfully; even if not it's much > easier converting the code by hand. > Doh, I forgot the most important bit: Use the keep preprocessed file option of your compiler. for gcc I think it's -E; in visual studio it's one of the options on the Preprocessor properties page. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk

== Quote from div0 (div0@sourceforge.net)'s article > On 12/11/2010 13:21, div0 wrote: > > On 12/11/2010 04:01, jfd wrote: > >> > >> Help, anyone? Thank you. > > > > The easiest way is to simply compile a one liner C module. > > Then you get all the necessary stuff included and all the irritating > > macros stripped out and converted to what they are actually supposed to > > be. You can then probably run htod successfully; even if not it's much > > easier converting the code by hand. > > > Doh, I forgot the most important bit: > Use the keep preprocessed file option of your compiler. > for gcc I think it's -E; in visual studio it's one of the options on the > Preprocessor properties page. This LLVM video at GoogleTechTalks illustrates my "pain index" -- in charts! Please see video starting at time 0:38:14: http://www.youtube.com/watch?v=VeRaLPupGks Thanks for the help!