-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
move @cImport
to the build system
#20630
Comments
A small extra note: this eliminates one quite common use case of |
@andrewrk would this mean that in order to interoperate with c, you need to use the zig build system? I have a small personal project written in c built using make files. Im currently extending it by writing new zig code that cIncludes header files and invoking the zig compiler from make (i.e zig build-obj). Would this use case not be supported anymore? |
You would just have to invoke |
@149-code, @alexrp -- note that once #16270 is implemented, In theory, you can have your |
Hm, that sounds a bit concerning. Not looking to relitigate #16270 all over again, but I'm on board with it because the promise was that existing use cases would still be supported - it just might involve downloading an extra package for all the C/C++ functionality (which is totally fair). But if Please don't get me wrong; I really like the Zig build system and I use it extensively in my "pure Zig" projects. But if we start making existing features of the |
I don't think any code generation would be required. You could write a single, generic build.zig that exposes a CLI pretty much identical to the current One could probably even write a zig package that provides a |
What ifreund says would work, but thinking about how the translate-c package is likely to work, it might not even be necessary. I would expect the translate-c package to expose an artifact, and users construct |
That sounds reasonable. My concern here was just the prospect of having to integrate all the machinery of the Zig build system as part of the build logic in my MSBuild SDK (which is currently just a So as long as there's a way to invoke The only other point I would add here is that I think it would be good to distribute such a |
Well, I think you have provided a quite interesting and valuable real world use case, so, let's work together to come up with a migration proposal that is appealing before proceeding with removal of |
To be clear @andrewrk, the use case described above doesn't depend on |
Ah thanks for that clarification. Well, point stands for that follow-up issue but I will remove it from the blocker list above. |
Adding my 2cts to heavily support this. We're using |
I really like to use the |
That's a given - the build system will invoke the translate-c tool as a subprocess using CLI args.
No, this use case will regress. |
@LouisLibre Your comment does not add anything of value to this discussion. A proposal like this weighs the benefits and drawbacks against each other to decide if the zig project as a whole would be improved by the proposal or not. Merely reiterating a single drawback with no nuance or discussion as you have done is useless noise. |
For “hello world from C” and bug-reproduction demos, it is useful to have C-interop without having to set up the build system. (The ongoing HN thread on this topic has several anecdotes from people convinced to try out Zig because of such simple demos.) For someone new to the language, setting up the build system at all represents significant complexity. However this use-case could be satisfied by adding an argument to This would continue to kick the can down the road with regards to #16270, but it may make sense in the short term (allowing both |
Keeping incorporating c header imports as a feature accessible to the CLI is important to the semantic analysis pass that happens as a part of Zigler. https://github.com/E-xyza/zigler (I'm also using this in prod and this week it's saving the bacon of the startup I'm at) |
@ityonemo can you be more specific? Seems like you should be fine with the |
I'm fine with deprecating @cImport, but just as the "zig module import" parameters (paths, deps) can be set via command line, if a module is imported as a c ABI, id want tobe able to do so via cli without resorting to build.zig. mentioning that zig run would regress is a bit worrying. For example, in 0.12 I can run I'm not exactly sure how the translate-c subcommands works (it sounds like it will? Maybe?) and I could probably figure it out, but I had lots of difficulty integrating a semantic pass with build.zig that lived side-by-side with the libs I generate, since I am doing sneaky things like substituting shims when running semantic analysis pass. |
@ityonemo the Anyway, here's a related issue I typed up just now. I think this is the actual issue that people are wanting to talk about today: |
Good to know. More than one command is not ideal, but it's fine! I could probably also figure out how to do it with build.zig, I just had enough trouble with it that I gave up last time :) |
Preperation for ziglang/zig#20630
From the perspective of an outsider, the fact that |
To be clear, there is an upgrade path, so if you learn how to use |
@cImport is being removed, see: ziglang/zig#20630
This issue is to remove the
@cImport
language builtin, instead relying on the feature being provided by the build system (std.Build.Step.TranslateC
).This removes one dependency on libclang inside the Zig compiler executable, which is required for #16270. In the near-term future, the translate-c implementation will still be inside the Zig compiler executable, along with the ability to compile C/C++ source files. However, we can prepare users for this transition by solving the use case via the build system rather than a language feature.
As a consolation prize, the TranslateC build step can be enhanced with advanced settings, such as namespace stripping and validation of existing bindings. Since changes to this don't require changing the language, it's OK if the scope & complexity increase to some extent.
Blockers:
Related:
bool
foundc_int
#19950The text was updated successfully, but these errors were encountered: