make dealing with zig.h less problematic

[andrewrk]

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 in lib/include/zig.h - next to the other C language headers (not to be confused with libc headers).

Problems with this setup:

• Having it sit next to other C language includes means that using 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.
• Versions can become mismatched.

This proposal:

• Move zig.h from lib/include/zig.h to lib/zig.h.
• When performing a C backend build, in addition to outputting the .c file, copy zig.h to the same directory, with a suffix of zig version. For example, zig build-exe foo.zig -ofmt=c would produce foo.c and zig-0.10.0.h in the current working directory.
• Change the include line from #include <zig.h> to #include "zig-$VERSION.h". This both adds a version suffix and makes it look in the same directory as itself.

[jacobly0]

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 git clean frequently enough that I wouldn't expect to be affected by it myself.

[andrewrk]

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.