-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
make dealing with zig.h less problematic #13528
Comments
I've been considering almost this exact proposal, and seeing it written down I'm not seeing any issues with it. The version number is certainly a nice addition for releases, although I wonder how much it might spam a bunch of unused dev versions of the file during development. This is of course mitigated by the version not changing until the commit changes, so it might be fine. I run |
I do think it's worth considering the alternative of going back to embedding zig.h - it does make some problems go away although it's not as nice for C backend development itself. However, a relevant consideration would be the use case where something compiled with the C backend wants to expose its API to other C code. Does its public API depend on zig.h or not? That seems like a whole other can of worms for which a decision can perhaps be delayed while we focus on other pressing matters. |
Partially implements #13528. Enough to unblock the wasi-bootstrap branch.
Partially implements #13528. Enough to unblock the wasi-bootstrap branch.
Is there a workaround for this, or is it not possible to generate a header file and then include it in the compilation of some C files all from within a I tried using |
Previously, the contents of zig.h were directly prepended to output .c files when using the C backend. It was extracted into an installation file in order to support the use case of editing zig.h without recompilation.
Currently, when using
-ofmt=c
, the output .c file has the first line of#include <zig.h>
.Within a Zig installation,
zig.h
can be found inlib/include/zig.h
- next to the other C language headers (not to be confused with libc headers).Problems with this setup:
zig cc
supports#include <zig.h>
without any-I
arguments. However, when using any other compiler, such as gcc, clang, or msvc, a-isystem
argument would be needed to make the include work. Passing the directory of the zig installation that contains zig.h causes conflicting C language headers to be in the system include path.This proposal:
zig.h
fromlib/include/zig.h
tolib/zig.h
.zig version
. For example,zig build-exe foo.zig -ofmt=c
would producefoo.c
andzig-0.10.0.h
in the current working directory.#include <zig.h>
to#include "zig-$VERSION.h"
. This both adds a version suffix and makes it look in the same directory as itself.The text was updated successfully, but these errors were encountered: