> 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.
> 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.
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?
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