digitalmars.D - Compile and link C/C++ libs automatically
- RSY (30/30) Dec 02 2020 Hello
- RSY (4/4) Dec 02 2020 Extra:
- Mike Parker (15/25) Dec 02 2020 LDC is not "based on clang". It's a D frontend to LLVM, whereas
- RSY (13/42) Dec 02 2020 The reason opting for an integrated solution is for efficiency!
- =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= (12/18) Dec 03 2020 Go make it even simpler and IMO that's the way to go:
- bachmeier (15/29) Dec 03 2020 I assume you're referring to cgo. I honestly don't see how that's
- =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= (11/18) Dec 05 2020 The tooling will use it in the background, you don't have to call it
- RSY (5/19) Dec 03 2020 I still prefer to have it separate, so you can add specific
- =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= (9/13) Dec 05 2020 No problem with Go. Just use:
- Jacob Carlborg (5/16) Dec 04 2020 This works in Zig as well. It's even simpler in Zig since you don't need...
- =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= (7/9) Dec 05 2020 Yes, absolutely. Zig is more low-level/bare metal than Go but very nice ...
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
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
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
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: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 everyoneHello 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
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 DUBGo 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
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: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.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 DUBGo 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.
Dec 03 2020
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
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: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 goalHowever, 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 DUBGo 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.
Dec 03 2020
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 goalNo 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
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
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