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

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?

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

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

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

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.

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

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

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

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