@cImport works without build.zig and even with build.zig requires no special configuration (ignoring linking).

As it is currently described, @import of C will require build.zig and specific configuration therein.

And form my experience from Rust that is much less ergonomic. Maybe Zig will do it better than Rust but who knows?

build.zig is on its way to being essential.

I consider that an appropriate development. Binaries need to be built, this should be integrated with the rest of the system in any modern language.

It's not incompatible with using something like CMake or Ninja either, it just puts certain responsibilities inside of build.zig. Where they belong.

I don't think that's the case. In general you can set up @import modules from the command line, and I'm not 100% sure but I think build.zig generally just templates a command line call anyways.

I don't think this DSL is finalized yet, but you can see on a linked issue what the build.zig to support @import of C looks like on nightly:

    const translate_c = b.addTranslateC(.{
        .root_source_file = b.path("src/c.h"),
        .target = target,
        .optimize = optimize,
    });
    exe.root_module.addImport("c", translate_c.createModule());

https://github.com/ziglang/zig/issues/20648

It won't require build.zig, you'll just have to run zig translate-c on the C file. Andrew's comment here[1] says that @cImport is basically @import + the compiler implicitly running translate-c for you. There was some discussion of removing the translate-c subcommand as well (which would force you to use build.zig), but I don't think it's been decided to do that.

[1] https://github.com/ziglang/zig/issues/20630#issuecomment-225...

> What's the problem? @cImport is becoming just @import.

You’re oversimplifying what’s actually a significant change.

Right now, I can do the following:

1. Download a prebuilt Zig release [0], on a fresh computer (zero prerequisites).

2. Implement a C library foo via foo.h and foo.c.

3. Compile foo.c into an object file foo.o via `zig cc`, using standard GNU-compatible compiler flags, for virtually any of the common (and even not-so-common) compilation targets.

4. Implement a Zig program bar via bar.zig.

5. Directly import foo.h into bar.zig via `@cImport` and use the C API as if it was Zig code.

6. Compile bar.zig and foo.o into a statically-linked executable baz via `zig build-exe`, for virtually any of the common (and even not-so-common) compilation targets.

No knowledge of the Zig build system and its semantics necessary. This is one of the most attractive aspects of Zig for a C programmer. I’ve gone through these exact steps with C programmers who thought Zig seemed interesting in theory but just didn’t want to have to learn a new ecosystem, build system, etc. The moment I showed them how quickly they could get up and running with Zig (and test it out with C code), without even having to install anything, it suddenly was impressive enough to experiment with.

The build system requirement may seem minor if you’re already a Zig programmer, but it’s massive if you want to attract C systems programmers.

[0]: https://ziglang.org/download

I think someone who doesn't know what they are talking about about is asserting a build.zig requirement. I don't know for sure, but probably it will work with the command line?

> The build system requirement may seem minor if you’re already a Zig programmer, but it’s massive if you want to attract C systems programmers.

You won't need knowledge of the build system nor a 'build.zig'.

After step 4 you would run 'zig translate-c' on 'foo.h'. Then use '@import' instead of '@cImport' in step 5 for the translated file.

'@cImport' is basically just doing that under the hood. It's an additional step for the user, that's a fair point, but I definitely wouldn't call it massive.