www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compile and link C/C++ libs automatically

reply RSY <rsy_881 gmail.com> writes:
Hello

I tried zig for few days last month, it was pretty fun, but D 
still remains my main language, zig is way too much restrictive 
and verbose..

However, one feature that is making me very jealous was the 
ability to compile c/c++ code and automatically link the lib, and 
cache all that

This made working with C libraries MUCH easier

Since both zig and LDC are based on clang, i was wondering if the 
same could be possible with LDC?

Example: https://github.com/yurapyon/maru/blob/master/build.zig#L8

Now imagine such feature, with DUB


You add:

```json
"c-sources": [
     {
         "file": "deps/stb/stb_image.c",
         "flags": "-std=c99"
     }
],
"c-headers": [
     "deps/stb/stb_image.h"
]
```

``c-sources`` to build the library

and

``h-headers`` to resolve symbols

And LDC does all the job for you, so we do not need to depend on 
a local C/C++ compiler anymore!


CC from: https://github.com/ldc-developers/ldc/issues/3627
Dec 02 2020
next sibling parent RSY <rsy_881 gmail.com> writes:
Extra:

I know Walter Bright made a C/C++ compiler in the past before DMD

So, what about DMD? is this feasible with the main compiler, or 
our only chance is with LDC, since it is based on clang?
Dec 02 2020
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 3 December 2020 at 05:08:55 UTC, RSY wrote:

 Hello

 I tried zig for few days last month, it was pretty fun, but D 
 still remains my main language, zig is way too much restrictive 
 and verbose..

 However, one feature that is making me very jealous was the 
 ability to compile c/c++ code and automatically link the lib, 
 and cache all that

 This made working with C libraries MUCH easier

 Since both zig and LDC are based on clang, i was wondering if 
 the same could be possible with LDC?


LDC is not "based on clang". It's a D frontend to LLVM, whereas 
clang is a C frontend to LLVM.

Personally, I don't find it very practical to maintain a 
multi-language compiler. If the Zig developers think it's the way 
to go, more power to them. But this is the sort of thing that 
should be relegated to build tools. Should we have support for 
compiling C and C++ in dub? Absolutely (you can do it now to a 
limited degree with prebuild commands). But not built into the D 
compiler. It should be configurable (gcc vs ldc vs msvc) just as 
dub allows you to choose your D compiler.

You might find dpp of interest. While it doesn't compile C or 
C++, it does allow you to include C  and (to a limited degree) 
C++ headers in your D code without the need to create bindings.

https://github.com/atilaneves/dpp
Dec 02 2020
parent RSY <rsy_881 gmail.com> writes:
On Thursday, 3 December 2020 at 06:13:10 UTC, Mike Parker wrote:

 On Thursday, 3 December 2020 at 05:08:55 UTC, RSY wrote:

 Hello

 I tried zig for few days last month, it was pretty fun, but D 
 still remains my main language, zig is way too much 
 restrictive and verbose..

 However, one feature that is making me very jealous was the 
 ability to compile c/c++ code and automatically link the lib, 
 and cache all that

 This made working with C libraries MUCH easier

 Since both zig and LDC are based on clang, i was wondering if 
 the same could be possible with LDC?


 LDC is not "based on clang". It's a D frontend to LLVM, whereas 
 clang is a C frontend to LLVM.

 Personally, I don't find it very practical to maintain a 
 multi-language compiler. If the Zig developers think it's the 
 way to go, more power to them. But this is the sort of thing 
 that should be relegated to build tools. Should we have support 
 for compiling C and C++ in dub? Absolutely (you can do it now 
 to a limited degree with prebuild commands). But not built into 
 the D compiler. It should be configurable (gcc vs ldc vs msvc) 
 just as dub allows you to choose your D compiler.

 You might find dpp of interest. While it doesn't compile C or 
 C++, it does allow you to include C  and (to a limited degree) 
 C++ headers in your D code without the need to create bindings.

 https://github.com/atilaneves/dpp


The reason opting for an integrated solution is for efficiency! 
caching should work just like D modules, no need to spawn extra 
processes, wich is slow on windows, no overheads at all, 
something that just works, out of the box

I still believe there is value in that, it allows everyone to 
consume the giant C ecosystem with ease, this is something nobody 
should underestimate!

Today linking libraries with dub is very easy, the compilation 
part is what pauses problems, specially when deciding to 
crosscompile for other targets.. this becomes very annoying!

Using clang as a library, could be a solution? something opt-in 
rather than opt-out to avoid imposing the dependency to everyone
Dec 02 2020
prev sibling parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 3 Dec 2020 at 06:08:55 CET, "RSY" <rsy_881 gmail.com> wrote:


 However, one feature that is making me very jealous was the 
 ability to compile c/c++ code and automatically link the lib, and 
 cache all that
 
 This made working with C libraries MUCH easier ...
 Now imagine such feature, with DUB


Go make it even simpler and IMO that's the way to go:

// <myinclude.>
Import "C"

And now use all your C functions and structs, etc.

That's the way to go. No extra tool, no pre-step conversion, no fiddling
around with separate files.

Just simple, straight import and you are done.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 03 2020
next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 3 December 2020 at 09:10:53 UTC, Robert M. Münch 
wrote:

 On 3 Dec 2020 at 06:08:55 CET, "RSY" <rsy_881 gmail.com> wrote:


 However, one feature that is making me very jealous was the 
 ability to compile c/c++ code and automatically link the lib, 
 and cache all that
 
 This made working with C libraries MUCH easier ...
 Now imagine such feature, with DUB


 Go make it even simpler and IMO that's the way to go:

 // <myinclude.>
 Import "C"

 And now use all your C functions and structs, etc.

 That's the way to go. No extra tool, no pre-step conversion, no 
 fiddling around with separate files.

 Just simple, straight import and you are done.


I assume you're referring to cgo. I honestly don't see how that's 
any easier than using dpp. It's been quite a few years now, but 
cgo was what attracted me to an otherwise bland language - I 
thought it would make it easy to solve my problems. cgo has its 
limitations (or maybe they are limitations of the language 
itself, I'm not sure). My recollection is that I gave up after a 
painful attempt trying to pass function pointers. Some 
limitations are listed here: https://golang.org/cmd/cgo/ For 
instance, "Go struct types are not supported; use a C struct 
type. Go array types are not supported; use a C pointer."

Overall the experience wasn't what I had hoped. Just to be clear, 
I'll repeat that I haven't used Go in ages, but "simple, straight 
import and you are done" was not my experience when I used cgo.
Dec 03 2020
parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 3 Dec 2020 at 13:38:58 CET, "bachmeier" <no spam.net> wrote:


 I assume you're referring to cgo.


Correct, it's a separate component but which mostly gets out of your way.


  I honestly don't see how that's any easier than using dpp.


The tooling will use it in the background, you don't have to call it
explicitly.


 My recollection is that I gave up after a 
 painful attempt trying to pass function pointers. Some 
 limitations are listed here: https://golang.org/cmd/cgo/ For 
 instance, "Go struct types are not supported; use a C struct 
 type. Go array types are not supported; use a C pointer."


I don't see this as an limitation. That's what you have to deal with when you
cross the chasm.

However, crossing the chasm needs to be simple and that's what it is.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 05 2020
prev sibling next sibling parent reply RSY <rsy_881 gmail.com> writes:
On Thursday, 3 December 2020 at 09:10:53 UTC, Robert M. Münch 
wrote:

 On 3 Dec 2020 at 06:08:55 CET, "RSY" <rsy_881 gmail.com> wrote:


 However, one feature that is making me very jealous was the 
 ability to compile c/c++ code and automatically link the lib, 
 and cache all that
 
 This made working with C libraries MUCH easier ...
 Now imagine such feature, with DUB


 Go make it even simpler and IMO that's the way to go:

 // <myinclude.>
 Import "C"

 And now use all your C functions and structs, etc.

 That's the way to go. No extra tool, no pre-step conversion, no 
 fiddling around with separate files.

 Just simple, straight import and you are done.



I still prefer to have it separate, so you can add specific 
compilation flags or defines

But yes, making such feature easily accessible is the goal
Dec 03 2020
parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 3 Dec 2020 at 21:01:33 CET, "RSY" <rsy_881 gmail.com> wrote:


 I still prefer to have it separate, so you can add specific 
 compilation flags or defines
 
 But yes, making such feature easily accessible is the goal


No problem with Go. Just use:

// #cgo windows LDFLAGS: -v ...
// #cgo windows CFLAGS: -I ..

So you can even use target specific ones.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 05 2020
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-12-03 10:10, Robert M. Münch wrote:


 Go make it even simpler and IMO that's the way to go:
 
 // <myinclude.>
 Import "C"
 
 And now use all your C functions and structs, etc.
 
 That's the way to go. No extra tool, no pre-step conversion, no fiddling
 around with separate files.
 
 Just simple, straight import and you are done.


This works in Zig as well. It's even simpler in Zig since you don't need 
a C compiler or linker. That's all built-in to the Zig compiler.

-- 
/Jacob Carlborg
Dec 04 2020
parent =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 4 Dec 2020 at 16:23:45 CET, "Jacob Carlborg" <doob me.com> wrote:


 This works in Zig as well. It's even simpler in Zig since you don't need 
 a C compiler or linker. That's all built-in to the Zig compiler.


Yes, absolutely. Zig is more low-level/bare metal than Go but very nice in
this sense.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Dec 05 2020