In my project i have 2 C libraries as dependency

It is annoying because my project is crossplatform, so i have to maintain build scripts for all platform.. and then i have to make sure the bindings with all the structs/externs are up to date..

So i decided to stop doing that and instead give ImportC a try, and so far... so good! I managed to remove one dependency already! I'm now working on removing the 2nd one (i got it to build on linux, i will have to test for windows)

There was few problems i had to workaround

typedef unsigned __int32 size_t;
typedef unsigned __int64 size_t;
__declspec(noreturn)

They refused to compile, i i had to come up with these defines as a workaround until it gets fixed (i reported the issues on the bug tracker)

workaround:

#define __int32 int
#define __int64 long
#define __declspec(noreturn)

There was also a member of a struct named: null, we can't use that in D, so i had to rename it (i will send a PR to the libraries repo, because 'null' is a bad name anyways :p)

And tadaa, it compiles, and it works!!

My renderer code in D (opengl stuff): https://gist.github.com/ryuukk/1c8b7af3265389ed94467bef2fd70d30

It calls directly into the nuklear.c module!

Thanks Walter for working on ImportC, it already is super useful, and i encourage everyone to try on their favorite library and report issues they encounter (and successes) to make ImportC even better!

After testing, next up i'll post about the next library, https://github.com/cesanta/mongoose

On Sunday, 26 June 2022 at 21:47:46 UTC, ryuukk_ wrote:

If there are oneortwo examples, and write an article for importC, that would be better.

On Sunday, 26 June 2022 at 21:47:46 UTC, ryuukk_ wrote:

D should investigate the user's favorite 'C' library, and then 'importC' should try to satisfy them .
This could be very good.

On Monday, 27 June 2022 at 00:34:26 UTC, zjh wrote:

I need to start a blog so i can write some articles that could be shared, writing is not my thing, but i should try, so i can improve

On Monday, 27 June 2022 at 00:52:59 UTC, ryuukk_ wrote:

Write blog is a good thing. You can not only read it over and over again as a memo, but also promote 'd', You can even advertise yourself.

On Sunday, 26 June 2022 at 21:47:46 UTC, ryuukk_ wrote:

Probably not until there is a reasonable way to map C files to D modules.

On Monday, 27 June 2022 at 12:00:52 UTC, Max Samukha wrote:

In Zig you can do this (which is useful for cross-compilation)

"Linking a library by source

But we also have a very different way of linking libraries with the Zig toolchain:

We can just compile them ourselves!

This gives us the benefit that we can much much easier cross-compile our programs. For this, we need to convert the libraries build files into our build.zig. This typically requires a pretty good understanding of both build.zig and the build system your library uses. But let's assume the library is super-simple and just consists of a bunch of C files:

pub fn build(b: *std.build.Builder) void {
    const cflags = [_][]const u8{};

    const curl = b.addSharedLibrary("curl", null, .unversioned);
    curl.addCSourceFile("vendor/libcurl/src/tool_main.c", &cflags);
    curl.addCSourceFile("vendor/libcurl/src/tool_msgs.c", &cflags);
    curl.addCSourceFile("vendor/libcurl/src/tool_dirhie.c", &cflags);
    curl.addCSourceFile("vendor/libcurl/src/tool_doswin.c", &cflags);

    const exe = b.addExecutable("chapter-3", "src/main.zig");
    exe.linkLibC();
    exe.addIncludeDir("vendor/libcurl/include");
    exe.linkLibrary(curl);
    exe.install();
}

With this, we can use both addSharedLibrary and addStaticLibrary to add libraries to our LibExeObjStep.

This is especially convenient as we can use setTarget and setBuildMode to compile from everywhere to everywhere." [1]

[1] https://zig.news/xq/zig-build-explained-part-3-1ima

On Monday, 27 June 2022 at 13:58:32 UTC, Chris wrote:

That's interesting. Unfortunately, I cannot afford to switch to Zig.

On Tuesday, 28 June 2022 at 12:44:39 UTC, Max Samukha wrote:

Zig supports C integration quite well[1]. But Zig is a bit more finicky than, say, GCC when it comes to undefined behavior[2], if you use the approach above. You can also compile C code with zig cc.

D does a decent job too, however, last time I used it, there was more work involved (e.g. tranlating structs). importC seems to be more like Zig's approach.

[1] https://ziglang.org/documentation/0.9.1/#C
[2] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

On Monday, 27 June 2022 at 12:00:52 UTC, Max Samukha wrote:

what do you mean exactly?

module nuklear;

public import nuklear_c; // .c file

import nk = nuklear; // neat trick

void main()
{
    nk.nk_init() ..
}

That's how i do it, works great so far