www.digitalmars.com         C & C++   DMDScript  

D.gnu - Carbon for D

reply Sha Chancellor <schancel pacific.net> writes:
I'm rather inexperienced in making interfaces for D.   I'm trying to
make a carbon interface for D. I tried SWIG with D but I get tons of errors in
the interface file i
made via:
gcc Carbon_stub.h -E -framework ..../Carbon.framework.  //Which
basically leaves me with one header file for all of Carbon.I added a %module
Carbon and tried to get it to generate me an
interface.
Am I even going about this in a sane manor?  Has anyone already done
this?  I tried to do this by hand before but there's nearly 900,000 lines
of code in this file. 
Jul 22 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
In message <cdp6k6$1286$1 digitaldaemon.com> 
 Sha Chancellor <schancel pacific.net> wrote: 

I'm rather inexperienced in making interfaces for D.   I'm trying to
made via:
gcc Carbon_stub.h -E -framework ..../Carbon.framework.  //Which
interface.
Am I even going about this in a sane manor?  Has anyone already done
this?  I tried to do this by hand before but there's nearly 900,000 lines
of code in this file. 
.

Whoops this was supposed to go into digitalmars.d.
Jul 22 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Sha Chancellor schrieb:

 Whoops this was supposed to go into digitalmars.d. 

No, this newsgroup is quite right. All people who are non-x86 are here. Look for "docoa" in this newsgroup by Owen "resistor". -eye
Jul 23 2004
parent reply resistor AT mac DOT com <resistor_member pathlink.com> writes:
Carbon isn't really my area of expertise and isn't part of Docoa, but I'll see
if I can help.

Carbon is a pure C API, so all you have to do is prototype the C functions and
structs inside a D module, and you're good to go.  Quite frankly, it'd be a lot
of work to make working prototypes for all of Carbon.  So unless that's actually
your intent, I'd suggest just prototype the functions you intend to use.

Good luck!

Owen

In article <cdquos$1s39$1 digitaldaemon.com>, Ilya Minkov says...
Sha Chancellor schrieb:

 Whoops this was supposed to go into digitalmars.d. 

No, this newsgroup is quite right. All people who are non-x86 are here. Look for "docoa" in this newsgroup by Owen "resistor". -eye

Jul 24 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
I suppose that's probably the best way for me to handle it.  Go a bit at a time.
I tried preprocessing Carbon/Carbon.h and running that through SWIG.  But no go.
I'll see how doing it one function at a time goes :)

In article <cdvgv5$1n3r$1 digitaldaemon.com>, resistor AT mac DOT com says...
Carbon isn't really my area of expertise and isn't part of Docoa, but I'll see
if I can help.

Carbon is a pure C API, so all you have to do is prototype the C functions and
structs inside a D module, and you're good to go.  Quite frankly, it'd be a lot
of work to make working prototypes for all of Carbon.  So unless that's actually
your intent, I'd suggest just prototype the functions you intend to use.

Good luck!

Owen

In article <cdquos$1s39$1 digitaldaemon.com>, Ilya Minkov says...
Sha Chancellor schrieb:

 Whoops this was supposed to go into digitalmars.d. 

No, this newsgroup is quite right. All people who are non-x86 are here. Look for "docoa" in this newsgroup by Owen "resistor". -eye


Jul 25 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Sha Chancellor" <schancel pacific.net> escribió en el mensaje
news:ce1ac5$2qj5$1 digitaldaemon.com
| I suppose that's probably the best way for me to handle it.  Go a bit at a
time.
| I tried preprocessing Carbon/Carbon.h and running that through SWIG.  But
no go.
| I'll see how doing it one function at a time goes :)
|
| In article <cdvgv5$1n3r$1 digitaldaemon.com>, resistor AT mac DOT com
says...
||
|| Carbon isn't really my area of expertise and isn't part of Docoa, but
I'll see
|| if I can help.
||
|| Carbon is a pure C API, so all you have to do is prototype the C
functions and
|| structs inside a D module, and you're good to go.  Quite frankly, it'd be
a lot
|| of work to make working prototypes for all of Carbon.  So unless that's
actually
|| your intent, I'd suggest just prototype the functions you intend to use.
||
|| Good luck!
||
|| Owen

I know nothing about Carbon, but I have a question regarding to what you
want to do: if Carbon is a "pure C API" (as Owen said), why are you using
SWIG? Isn't SWIG supposed to be for C++ code? With a bit of luck, even the
pure preprocessor output can be accepted by the D compiler (gdc in this
case, I assume), otherwise you'll have to tweak it a bit.
Now, of course, the ideal solution would be for someone (not me, sorry) to
write an automatic C header to D import module converter, the everyone could
use it for any C library. Are you up for it? ;)

-----------------------
Carlos Santander Bernal
Jul 25 2004
next sibling parent reply resistor AT mac DOT com <resistor_member pathlink.com> writes:
http://www.dsource.org/projects/h2d/

-Owen

In article <ce1cql$2s6s$1 digitaldaemon.com>, Carlos Santander B. says...
"Sha Chancellor" <schancel pacific.net> escribió en el mensaje
news:ce1ac5$2qj5$1 digitaldaemon.com
| I suppose that's probably the best way for me to handle it.  Go a bit at a
time.
| I tried preprocessing Carbon/Carbon.h and running that through SWIG.  But
no go.
| I'll see how doing it one function at a time goes :)
|
| In article <cdvgv5$1n3r$1 digitaldaemon.com>, resistor AT mac DOT com
says...
||
|| Carbon isn't really my area of expertise and isn't part of Docoa, but
I'll see
|| if I can help.
||
|| Carbon is a pure C API, so all you have to do is prototype the C
functions and
|| structs inside a D module, and you're good to go.  Quite frankly, it'd be
a lot
|| of work to make working prototypes for all of Carbon.  So unless that's
actually
|| your intent, I'd suggest just prototype the functions you intend to use.
||
|| Good luck!
||
|| Owen

I know nothing about Carbon, but I have a question regarding to what you
want to do: if Carbon is a "pure C API" (as Owen said), why are you using
SWIG? Isn't SWIG supposed to be for C++ code? With a bit of luck, even the
pure preprocessor output can be accepted by the D compiler (gdc in this
case, I assume), otherwise you'll have to tweak it a bit.
Now, of course, the ideal solution would be for someone (not me, sorry) to
write an automatic C header to D import module converter, the everyone could
use it for any C library. Are you up for it? ;)

-----------------------
Carlos Santander Bernal

Jul 25 2004
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"resistor AT mac DOT com" <resistor_member pathlink.com> escribió en el
mensaje
news:ce1h6a$2upn$1 digitaldaemon.com
| http://www.dsource.org/projects/h2d/
|
| -Owen
|

But it seems sooooo dead....

-----------------------
Carlos Santander Bernal
Jul 26 2004
prev sibling parent reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
"Carlos Santander B." wrote:

 "Sha Chancellor" <schancel pacific.net> escribió en el mensaje
 news:ce1ac5$2qj5$1 digitaldaemon.com
 | I suppose that's probably the best way for me to handle it.  Go a bit at a
 time.
 | I tried preprocessing Carbon/Carbon.h and running that through SWIG.  But
 no go.
 | I'll see how doing it one function at a time goes :)
 |
 | In article <cdvgv5$1n3r$1 digitaldaemon.com>, resistor AT mac DOT com
 says...
 ||
 || Carbon isn't really my area of expertise and isn't part of Docoa, but
 I'll see
 || if I can help.
 ||
 || Carbon is a pure C API, so all you have to do is prototype the C
 functions and
 || structs inside a D module, and you're good to go.  Quite frankly, it'd be
 a lot
 || of work to make working prototypes for all of Carbon.  So unless that's
 actually
 || your intent, I'd suggest just prototype the functions you intend to use.
 ||
 || Good luck!
 ||
 || Owen

 I know nothing about Carbon, but I have a question regarding to what you
 want to do: if Carbon is a "pure C API" (as Owen said), why are you using
 SWIG? Isn't SWIG supposed to be for C++ code? With a bit of luck, even the
 pure preprocessor output can be accepted by the D compiler (gdc in this
 case, I assume), otherwise you'll have to tweak it a bit.
 Now, of course, the ideal solution would be for someone (not me, sorry) to
 write an automatic C header to D import module converter, the everyone could
 use it for any C library. Are you up for it? ;)

 -----------------------
 Carlos Santander Bernal

I have been looking into using SWIG to interface both C and C++ to D. The basic work had been done by Andy Friesen. SWIG provides a way of generating the interfaces for C++ or C. It is true that for C it generates a layer of C code which could be avoided, but it would make it quick to generate a lot of interface functions, selecting the ones you want from a big header file. See http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig for some details John
Jul 27 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
In article <41062AEB.E7B0E64C aston.ac.uk>,
 John Fletcher <J.P.Fletcher aston.ac.uk> wrote:

 I have been looking into using SWIG to interface both C and C++ to D. The 
 basic
 work had been done by Andy Friesen.
 
 SWIG provides a way of generating the interfaces for C++ or C.  It is true 
 that
 for C it generates a layer of C code which could be avoided, but it would 
 make
 it quick to generate a lot of interface functions, selecting the ones you 
 want
 from a big header file.
 
 See http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig for some details
 
 John

I used Andy Friesen's version and it didn't understand structs embedded in structs and gave me hundreds of errors. Also, I still see no link to download your modified version of SWIG from that page. Sha
Jul 27 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Sha Chancellor wrote:

 I used Andy Friesen's version and it didn't understand structs embedded 
 in structs and gave me hundreds of errors.  
 
 Also, I still see no link to download your modified version of SWIG from 
 that page.

wow. To start, that SWIG build was originally meant to be a sort of proof-of-concept. It's heavily based on the Java backend, and therefore does quite a lot of stupid things. :) Lately, I've started writing a fresh backend from scratch, if for no other reason than to get the hell away from the existing code, which is entirely too dense and poorly documented for its own good. (single-character variable names in 100+ line functions are a bad sign :) ) My present focus has been generating C proxies for C++ member functions, with limited generation of D import modules. (basically, lots of extern(C) things) Currently, it's only a little bit less useless than the last version I put up, but quite a lot more straightforward. I'll try and upload something tonight. -- andy
Jul 27 2004
parent Sha Chancellor <schancel pacific.net> writes:
In article <ce6q6o$2oa4$1 digitaldaemon.com>,
 Andy Friesen <andy ikagames.com> wrote:

 wow.
 
 To start, that SWIG build was originally meant to be a sort of 
 proof-of-concept.  It's heavily based on the Java backend, and therefore 
 does quite a lot of stupid things. :)
 
 Lately, I've started writing a fresh backend from scratch, if for no 
 other reason than to get the hell away from the existing code, which is 
 entirely too dense and poorly documented for its own good. 
 (single-character variable names in 100+ line functions are a bad sign :) )
 
 My present focus has been generating C proxies for C++ member functions, 
 with limited generation of D import modules. (basically, lots of 
 extern(C) things)
 
 Currently, it's only a little bit less useless than the last version I 
 put up, but quite a lot more straightforward.
 
 I'll try and upload something tonight.
 
   -- andy

Can't wait to see the results :) - Sha
Jul 28 2004
prev sibling parent John Fletcher <John_member pathlink.com> writes:
In article <schancel-81C1EE.11041427072004 digitalmars.com>, Sha Chancellor
says...
In article <41062AEB.E7B0E64C aston.ac.uk>,
 John Fletcher <J.P.Fletcher aston.ac.uk> wrote:

 I have been looking into using SWIG to interface both C and C++ to D. The 
 basic
 work had been done by Andy Friesen.
 
 SWIG provides a way of generating the interfaces for C++ or C.  It is true 
 that
 for C it generates a layer of C code which could be avoided, but it would 
 make
 it quick to generate a lot of interface functions, selecting the ones you 
 want
 from a big header file.
 
 See http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig for some details
 
 John

I used Andy Friesen's version and it didn't understand structs embedded in structs and gave me hundreds of errors. Also, I still see no link to download your modified version of SWIG from that page. Sha

My modifications to SWIG with DMD are now available from http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig John
Jul 28 2004