www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and C APIs

reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
I am guessing that people have an answer to this:

D making use of a C API needs a D module adapter. This can either be
constructed by hand (well it can, but=E2=80=A6), or it can be auto generate=
d
from the C header files and then hand massaged (likely far better). I
think the only tool for this on Linux is DStep.

This is all very well for a static unchanging API, but what about C
APIs that are generated from elsewhere? This requires constant update
of the D modules. Do people just do this by hand?

Is the pain of creating a V4L D module set worth the effort rather than
just suffering the pain of writing in C++?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 11
next sibling parent reply stew <growlercab gmail.com> writes:
On Monday, 11 January 2016 at 17:25:26 UTC, Russel Winder wrote:
 I am guessing that people have an answer to this:

 D making use of a C API needs a D module adapter. This can 
 either be constructed by hand (well it can, but…), or it can be 
 auto generated from the C header files and then hand massaged 
 (likely far better). I think the only tool for this on Linux is 
 DStep.

 This is all very well for a static unchanging API, but what 
 about C APIs that are generated from elsewhere? This requires 
 constant update of the D modules. Do people just do this by 
 hand?

 Is the pain of creating a V4L D module set worth the effort 
 rather than just suffering the pain of writing in C++?
At work we use CMake and have a target for this. The DStep target is invoked whenever the C headers change. We also use SWIG this way. Both tools often require some hand-massaging though. I am yet try this with dub but it's on my todo list. cheers, Stew
Jan 11
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2016-01-11 at 21:42 +0000, stew via Digitalmars-d wrote:
=20
[=E2=80=A6]
 At work we use CMake and have a target for this. The DStep target=C2=A0
 is invoked whenever the C headers change. We also use SWIG this=C2=A0
 way. Both tools often require some hand-massaging though.
[=E2=80=A6] I tried downloading pre-built Linux DStep, but it requires an .so link that doesn't exist on Debian Sid or Fedora Rawhide. I hacked something and DStep segfaulted. Given the long list of dependencies that aren't seemingly easily installed on Debian Sid or Fedora Rawhide, I am hesitant to build from source. So as to progress the project at all at this stage I am using C++. Sad, but pragmatic. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 12
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-12 11:39, Russel Winder via Digitalmars-d wrote:

 I tried downloading pre-built Linux DStep, but it requires an .so link
 that doesn't exist on Debian Sid or Fedora Rawhide. I hacked something
 and DStep segfaulted.
I assume you mean LLVM. Have you tried one from here [1]. Should work with LLVM 3.1 to 3.5 (at least). This is the matrix of Clang versions that I use for testing [2]. [1] http://llvm.org/releases/ [2] https://github.com/jacob-carlborg/dstep/blob/master/test.d#L233 -- /Jacob Carlborg
Jan 12
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-12 13:13, Jacob Carlborg wrote:

 I assume you mean LLVM. Have you tried one from here [1].
I use the Ubuntu releases to test on Debian 7 (64bit) and 6 (32bit). -- /Jacob Carlborg
Jan 12
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2016-01-12 at 13:13 +0100, Jacob Carlborg via Digitalmars-d
wrote:
=20
[=E2=80=A6]
 I assume you mean LLVM. Have you tried one from here [1]. Should
 work=C2=A0
 with LLVM 3.1 to 3.5 (at least). This is the matrix of Clang
 versions=C2=A0
 that I use for testing [2].
=20
=20
 [1] http://llvm.org/releases/
 [2] https://github.com/jacob-carlborg/dstep/blob/master/test.d#L233
I tried on Debian Sid. I have both LLVM 3.6 and 3.7 installed (3.6 is still the default but I am using 3.7 to build LDC. I have yet to try on Fedora Rawhide. The downloaded DStep executable requires a link to libclang.so which does not exist on Debian Sid. There is a libclang.so.1 in both the 3.6 and 3.7 lib directories. I provided the symbolic link: libclang.so -> /usr/lib/x86_64-linux-gnu/libclang-3.7.so.1 which satisfied ldd, but on execution got a segfault. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 12
parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 12 January 2016 at 13:17:16 UTC, Russel Winder wrote:
 On Tue, 2016-01-12 at 13:13 +0100, Jacob Carlborg via 
 Digitalmars-d wrote:
 [...]
[…]
 [...]
I tried on Debian Sid. I have both LLVM 3.6 and 3.7 installed (3.6 is still the default but I am using 3.7 to build LDC. I have yet to try on Fedora Rawhide. The downloaded DStep executable requires a link to libclang.so which does not exist on Debian Sid. There is a libclang.so.1 in both the 3.6 and 3.7 lib directories. I provided the symbolic link: libclang.so -> /usr/lib/x86_64-linux-gnu/libclang-3.7.so.1 which satisfied ldd, but on execution got a segfault.
Can you link which headers you're trying to translate?
Jan 12
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 11 January 2016 at 17:25:26 UTC, Russel Winder wrote:
 I am guessing that people have an answer to this:

 D making use of a C API needs a D module adapter. This can 
 either be constructed by hand (well it can, but…), or it can be 
 auto generated from the C header files and then hand massaged 
 (likely far better). I think the only tool for this on Linux is 
 DStep.

 This is all very well for a static unchanging API, but what 
 about C APIs that are generated from elsewhere? This requires 
 constant update of the D modules. Do people just do this by 
 hand?

 Is the pain of creating a V4L D module set worth the effort 
 rather than just suffering the pain of writing in C++?
This is the kind of thing I wrote reggae for. CMake is an alternative, but I'd rather write D than CMake script. Atila
Jan 12
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2016-01-12 at 08:12 +0000, Atila Neves via Digitalmars-d wrote:
 On Monday, 11 January 2016 at 17:25:26 UTC, Russel Winder wrote:
 I am guessing that people have an answer to this:
=20
 D making use of a C API needs a D module adapter. This can=C2=A0
 either be constructed by hand (well it can, but=E2=80=A6), or it can be=
=C2=A0
 auto generated from the C header files and then hand massaged=C2=A0
 (likely far better). I think the only tool for this on Linux is=C2=A0
 DStep.
=20
 This is all very well for a static unchanging API, but what=C2=A0
 about C APIs that are generated from elsewhere? This requires=C2=A0
 constant update of the D modules. Do people just do this by=C2=A0
 hand?
=20
 Is the pain of creating a V4L D module set worth the effort=C2=A0
 rather than just suffering the pain of writing in C++?
=20 This is the kind of thing I wrote reggae for. CMake is an=C2=A0 alternative, but I'd rather write D than CMake script.
CMake scripts are hideous in that the language is like nothing else, other than perhaps m4 macros. They should have used Lisp. Or Python. I must try Reggae at some stage, but for now I need to progress this Me TV rewrite. D and Rust provide so many barriers to effective use of a C library, that I am resorting to using C++. Yes you have to do extra stuff to avoid writing C code, but nowhere near the amount you have to to create D and Rust adaptors. Also using CMake and C++ I can use CLion, which seems to be far outstripping Eclipse/CDT and Netbeans as a C++ IDE. I still really dislike CMake scripts though. =C2=A0 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 12
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 12 January 2016 at 10:43:40 UTC, Russel Winder wrote:
 On Tue, 2016-01-12 at 08:12 +0000, Atila Neves via 
 Digitalmars-d wrote:
 On Monday, 11 January 2016 at 17:25:26 UTC, Russel Winder 
 wrote:
 I am guessing that people have an answer to this:
 
 D making use of a C API needs a D module adapter. This can 
 either be constructed by hand (well it can, but…), or it can 
 be auto generated from the C header files and then hand 
 massaged (likely far better). I think the only tool for this 
 on Linux is DStep.
 
 This is all very well for a static unchanging API, but what 
 about C APIs that are generated from elsewhere? This 
 requires constant update of the D modules. Do people just do 
 this by hand?
 
 Is the pain of creating a V4L D module set worth the effort 
 rather than just suffering the pain of writing in C++?
This is the kind of thing I wrote reggae for. CMake is an alternative, but I'd rather write D than CMake script.
CMake scripts are hideous in that the language is like nothing else, other than perhaps m4 macros. They should have used Lisp. Or Python. I must try Reggae at some stage, but for now I need to progress this Me TV rewrite. D and Rust provide so many barriers to effective use of a C library, that I am resorting to using C++. Yes you have to do extra stuff to avoid writing C code, but nowhere near the amount you have to to create D and Rust adaptors.
What's so hard about writing a few function prototypes, aliases and enums? It's annoying that we have to do it, but compared to writing the rest of a project it's always going to be a tiny amount of work. For a lot of projects you can only bind what you actually need, I often just pretend that I have already written the bindings then write whatever lines are necessary to get it to compile!
Jan 12
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 12 January 2016 at 11:05:38 UTC, John Colvin wrote:
 On Tuesday, 12 January 2016 at 10:43:40 UTC, Russel Winder 
 wrote:
 On Tue, 2016-01-12 at 08:12 +0000, Atila Neves via 
 Digitalmars-d wrote:
 On Monday, 11 January 2016 at 17:25:26 UTC, Russel Winder 
 wrote:
 [...]
This is the kind of thing I wrote reggae for. CMake is an alternative, but I'd rather write D than CMake script.
CMake scripts are hideous in that the language is like nothing else, other than perhaps m4 macros. They should have used Lisp. Or Python. I must try Reggae at some stage, but for now I need to progress this Me TV rewrite. D and Rust provide so many barriers to effective use of a C library, that I am resorting to using C++. Yes you have to do extra stuff to avoid writing C code, but nowhere near the amount you have to to create D and Rust adaptors.
What's so hard about writing a few function prototypes, aliases and enums? It's annoying that we have to do it, but compared to writing the rest of a project it's always going to be a tiny amount of work.
What's hard is that the function prototypes usually use/need: . macros . struct definitions Without a C preprocessor it's extremely hard to bind to any non-toy C API. It's the only reason I'd consider using C++ instead of D. But only after trying DStep first. Atila
Jan 12
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2016-01-12 at 11:05 +0000, John Colvin via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 What's so hard about writing a few function prototypes, aliases=C2=A0
 and enums? It's annoying that we have to do it, but compared to=C2=A0
 writing the rest of a project it's always going to be a tiny=C2=A0
 amount of work.
I started there but gave up quite quickly as there are two levels of API here, both of which are needed to use the higher-level API as it refers directly to low-level structs and stuff. There is the kernel device drivers level, which defines the low-level API, and then there is libdvd5 which provides a (slightly) higher C API =E2=80=93 with all the idiocies of a C API for doing high-level library programming :-( I have found a Rust wrapper of the kernel API, but that would mean writing all the libdvbv5 equivalent myself before writing the application code. There is no equivalent D version and certainly no easy way of wrapping libdvbv5 in D without it. Go has problems with C APIs and no sensible GTK3 wrapper.
 For a lot of projects you can only bind what you actually need, I=C2=A0
 often just pretend that I have already written the bindings then=C2=A0
 write whatever lines are necessary to get it to compile!
The problem is that this is easy in C++ for a C API, but not for D or Rust using the same C API. C++ can use the C stuff directly, D and Rust need an adaptor. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 12
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 12 January 2016 at 13:24:48 UTC, Russel Winder wrote:
 On Tue, 2016-01-12 at 11:05 +0000, John Colvin via 
 Digitalmars-d wrote:
 […]
 
 What's so hard about writing a few function prototypes, 
 aliases and enums? It's annoying that we have to do it, but 
 compared to writing the rest of a project it's always going to 
 be a tiny amount of work.
I started there but gave up quite quickly as there are two levels of API here, both of which are needed to use the higher-level API as it refers directly to low-level structs and stuff. There is the kernel device drivers level, which defines the low-level API, and then there is libdvd5 which provides a (slightly) higher C API – with all the idiocies of a C API for doing high-level library programming :-( I have found a Rust wrapper of the kernel API, but that would mean writing all the libdvbv5 equivalent myself before writing the application code. There is no equivalent D version and certainly no easy way of wrapping libdvbv5 in D without it. Go has problems with C APIs and no sensible GTK3 wrapper.
 For a lot of projects you can only bind what you actually 
 need, I often just pretend that I have already written the 
 bindings then write whatever lines are necessary to get it to 
 compile!
The problem is that this is easy in C++ for a C API, but not for D or Rust using the same C API. C++ can use the C stuff directly, D and Rust need an adaptor.
I agree it's easier in C++, but what I mean is literally doing something like: 1) write code pretending you've got complete bindings 2) try to compile 3) write the bare minimum bindings necessary to make it compile 4) goto 1 It's amazing how little of an API often ends up being used and therefore how little binding code you have to write. Alternatively you can write the bindings immediately when you use them, but I prefer not having to do the context switch between writing application and bindings quite as often as that.
Jan 12
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 12 January 2016 at 14:10:02 UTC, John Colvin wrote:
 On Tuesday, 12 January 2016 at 13:24:48 UTC, Russel Winder 
 wrote:
 On Tue, 2016-01-12 at 11:05 +0000, John Colvin via 
 Digitalmars-d wrote:
 […]
 
 What's so hard about writing a few function prototypes, 
 aliases and enums? It's annoying that we have to do it, but 
 compared to writing the rest of a project it's always going 
 to be a tiny amount of work.
I started there but gave up quite quickly as there are two levels of API here, both of which are needed to use the higher-level API as it refers directly to low-level structs and stuff. There is the kernel device drivers level, which defines the low-level API, and then there is libdvd5 which provides a (slightly) higher C API – with all the idiocies of a C API for doing high-level library programming :-( I have found a Rust wrapper of the kernel API, but that would mean writing all the libdvbv5 equivalent myself before writing the application code. There is no equivalent D version and certainly no easy way of wrapping libdvbv5 in D without it. Go has problems with C APIs and no sensible GTK3 wrapper.
 For a lot of projects you can only bind what you actually 
 need, I often just pretend that I have already written the 
 bindings then write whatever lines are necessary to get it to 
 compile!
The problem is that this is easy in C++ for a C API, but not for D or Rust using the same C API. C++ can use the C stuff directly, D and Rust need an adaptor.
I agree it's easier in C++, but what I mean is literally doing something like: 1) write code pretending you've got complete bindings 2) try to compile 3) write the bare minimum bindings necessary to make it compile 4) goto 1 It's amazing how little of an API often ends up being used and therefore how little binding code you have to write. Alternatively you can write the bindings immediately when you use them, but I prefer not having to do the context switch between writing application and bindings quite as often as that.
It's a nice technique that I hadn't thought about, and I'll definitely try it. I won't always work, though. At work we write our own operating systems with loooooads of platform headers. Every function definition depends on struct definitions that are in other headers which are generated from macros that.... you get the point. Unless, of course, I give up on accessing struct members from D, pass everything as void* and write C accessors. Which is a pain, especially compared to: extern "C" { #include "foo.h" #include "bar.h" } Atila
Jan 13
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 12 January 2016 at 10:43:40 UTC, Russel Winder wrote:
 D and Rust provide so many barriers to effective use of a C 
 library, that I am resorting to using C++. Yes you have to do 
 extra stuff to avoid writing C code, but nowhere near the 
 amount you have to to create D and Rust adaptors.
Sorry I can't offer any help, but I'm genuinely curious by what you mean in this part of your quote. If the API is changing, how does using C++, or for that matter C, help you? Sure, you can include the header directly in your program, but don't you still have to change your program? I must be missing something.
Jan 12
next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2016-01-12 at 12:56 +0000, bachmeier via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Sorry I can't offer any help, but I'm genuinely curious by what=C2=A0
 you mean in this part of your quote. If the API is changing, how=C2=A0
 does using C++, or for that matter C, help you? Sure, you can=C2=A0
 include the header directly in your program, but don't you still=C2=A0
 have to change your program? I must be missing something.
There are two APIs, the kernel/device driver and the library over it. libdvbv5 is trying to provide an unchanging adaptor and in many ways succeeds admirably (as long as you are happy with all the dreadful low- level things you have to do to do input/output and map/dictionaries). The kernel/device driver API changes as it needs to without worrying about backward compatibility, leaving consistency and compatibility to libdvbv5. However libdvbv5 exposes some symbols and structures (that don't actually change that much) directly in the libdvbv5 API. Thus you actually have to wrap both APIs to do anything useful. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 12
prev sibling parent reply Atla Neves <atila.neves gmail.com> writes:
On Tuesday, 12 January 2016 at 12:56:39 UTC, bachmeier wrote:
 On Tuesday, 12 January 2016 at 10:43:40 UTC, Russel Winder 
 wrote:
 D and Rust provide so many barriers to effective use of a C 
 library, that I am resorting to using C++. Yes you have to do 
 extra stuff to avoid writing C code, but nowhere near the 
 amount you have to to create D and Rust adaptors.
Sorry I can't offer any help, but I'm genuinely curious by what you mean in this part of your quote. If the API is changing, how does using C++, or for that matter C, help you? Sure, you can include the header directly in your program, but don't you still have to change your program? I must be missing something.
In C/C++, a change to the headers causes a recompilation which will fail if there are API changes. From any other language, it'll compile, link, and fail at runtime (unless the symbols change name). If you're lucky in an obvious way. Atila
Jan 12
parent bachmeier <no spam.com> writes:
On Tuesday, 12 January 2016 at 16:21:40 UTC, Atla Neves wrote:

 In C/C++, a change to the headers causes a recompilation which 
 will fail if there are API changes. From any other language, 
 it'll compile, link, and fail at runtime (unless the symbols 
 change name). If you're lucky in an obvious way.

 Atila
It's true that working directly with the upstream header file will catch errors that are not caught at compile time in other languages, but that's only an issue if you're not testing the calls you're making to the API. A couple of simple examples where replacing the old header with the new is not a good substitute for testing in the presence of arbitrary changes: 1. There's a change in the return value from 0=success to 0=failure. Then your program every so often dies with a segfault somewhere else, and it takes two days to track down the problem. 2. The function body stays the same but the signature changes from int foo(int x, int y) to int foo(int y, int x). Suddenly you're dividing by zero with previously working code.
Jan 12
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 12 January 2016 at 10:43:40 UTC, Russel Winder wrote:
 On Tue, 2016-01-12 at 08:12 +0000, Atila Neves via 
 Digitalmars-d wrote:
 On Monday, 11 January 2016 at 17:25:26 UTC, Russel Winder 
 wrote:
 [...]
This is the kind of thing I wrote reggae for. CMake is an alternative, but I'd rather write D than CMake script.
CMake scripts are hideous in that the language is like nothing else, other than perhaps m4 macros. They should have used Lisp. Or Python.
You can also write build descriptions in Python with reggae BTW. Atila
Jan 12
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2016-01-12 at 13:12 +0000, Atila Neves via Digitalmars-d wrote:
=20
[=E2=80=A6]
 You can also write build descriptions in Python with reggae BTW.
Splendid. Python 3 I trust. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 12
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Many times I've considered simply incorporating a C compiler into the D 
compiler, and then:

   import "stdio.h";

The perennial problem, however, is the C preprocessor and all the bizarre
things 
people do with it in even the most mundane header files. The problem is NOT, 
however, implementing the preprocessor, as that's already done. The problem is
C 
#include files do not exist in a vacuum; they derive their meaning based on the 
compiler used, the predefined macros, and the host file they were #include'd in.

Well, and the inevitable C language extensions, different for every compiler, 
and the developers determined to use every last one of them :-(

Then there's what type does 'char' map to?

When the D compiler guesses wrong about all these issues, there's no way to see 
or correct what it did, and so we wind up with endless "bugs" and support
issues.

It's better to have a separate translator, and the user can tweak the results
of it.
Jan 12
parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 12 January 2016 at 18:59:01 UTC, Walter Bright wrote:
 Many times I've considered simply incorporating a C compiler 
 into the D compiler, and then:

   import "stdio.h";

 The perennial problem, however, is the C preprocessor and all 
 the bizarre things people do with it in even the most mundane 
 header files. The problem is NOT, however, implementing the 
 preprocessor, as that's already done. The problem is C #include 
 files do not exist in a vacuum; they derive their meaning based 
 on the compiler used, the predefined macros, and the host file 
 they were #include'd in.

 Well, and the inevitable C language extensions, different for 
 every compiler, and the developers determined to use every last 
 one of them :-(

 Then there's what type does 'char' map to?

 When the D compiler guesses wrong about all these issues, 
 there's no way to see or correct what it did, and so we wind up 
 with endless "bugs" and support issues.

 It's better to have a separate translator, and the user can 
 tweak the results of it.
I understand the issues. But the reality remains that since any C++ compiler is also a C compiler, the same one will get used to parse the headers and the C++ code that includes it. The result being that 99.9% of the time I can write C++ code that #includes the C headers and not have to think about it (the other 0.1% are the parts of C that are incompatible with C++ - people think this is 0 but it isn't). It's the _only_ reason I'd personally choose to call C from C++ instead of D. And, unfortunately, a decision I made weeks ago. This discussion has made me want to try DStep again on the weird headers that I have and file bugs if it doesn't work. Atila
Jan 13