cImport going away

Explain
,
9

Can you explain on what basis you are saying it will be more cumbersome?

We’ve not decided exactly in which ways we’re going to extend the std.Build.Step.TranslateC APIs, if any, but I personally (emphasis to make sure nobody is taking this API as a promise!) picture it as working something like the following.

Today, you write this:

const c = @cImport({
    @cDefine("FOO", "123");
    @cUndef("BAR");
    @cInclude("qux.h");
});

Post-changes, you write this:

// build script:
exe.root_module.addTranslateCImport("c",
    \\#define FOO 123
    \\#undef BAR
    \\#include <qux.h>
);
// source code:
const c = @import("c");

After we eventually transition Clang to a package, the build system usage will inevitably look a little different again, but not significantly.

This really doesn’t seem any more awkward. If you want to go by a naive SLOC metric, it is a single extra line total. If you have justifiable reason to believe that such an API won’t happen, or an argument as to why it will be significantly more difficult to use and thus worth retaining the language complexity inherent in @cImport, I’d love to hear it.

6 Likes