• Russel Winder via Digitalmars-d (21/21) Jan 11 2016 I am guessing that people have an answer to this:
• stew (7/19) Jan 11 2016 At work we use CMake and have a target for this. The DStep target
• Russel Winder via Digitalmars-d (21/25) Jan 12 2016 [=E2=80=A6]
• Jacob Carlborg (8/11) Jan 12 2016 I assume you mean LLVM. Have you tried one from here [1]. Should work
• Jacob Carlborg (4/5) Jan 12 2016 I use the Ubuntu releases to test on Debian 7 (64bit) and 6 (32bit).
• Russel Winder via Digitalmars-d (21/31) Jan 12 2016 [=E2=80=A6]
• Joakim (2/16) Jan 12 2016 Can you link which headers you're trying to translate?
• Atila Neves (4/16) Jan 12 2016 This is the kind of thing I wrote reggae for. CMake is an
• Russel Winder via Digitalmars-d (23/42) Jan 12 2016 CMake scripts are hideous in that the language is like nothing else,
• John Colvin (8/39) Jan 12 2016 What's so hard about writing a few function prototypes, aliases
• Atila Neves (8/33) Jan 12 2016 What's hard is that the function prototypes usually use/need:
• Russel Winder via Digitalmars-d (26/35) Jan 12 2016 I started there but gave up quite quickly as there are two levels of
• John Colvin (12/40) Jan 12 2016 I agree it's easier in C++, but what I mean is literally doing
• Atila Neves (16/62) Jan 13 2016 It's a nice technique that I hadn't thought about, and I'll
• bachmeier (6/10) Jan 12 2016 Sorry I can't offer any help, but I'm genuinely curious by what
• Russel Winder via Digitalmars-d (21/27) Jan 12 2016 There are two APIs, the kernel/device driver and the library over it.
• Atla Neves (6/17) Jan 12 2016 In C/C++, a change to the headers causes a recompilation which
• bachmeier (13/18) Jan 12 2016 It's true that working directly with the upstream header file
• Atila Neves (3/14) Jan 12 2016 You can also write build descriptions in Python with reggae BTW.
• Russel Winder via Digitalmars-d (13/15) Jan 12 2016 Splendid. Python 3 I trust.
• Walter Bright (14/14) Jan 12 2016 Many times I've considered simply incorporating a C compiler into the D
• Atila Neves (13/32) Jan 13 2016 I understand the issues. But the reality remains that since any

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

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

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

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

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

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

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?

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

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

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!

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

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

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.

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

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.

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

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

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.

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

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

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.

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