[IDEA] Add options if generates c_header for zig_library/zig_shared_library and provide CCInfo for other cc_library can depends on it

[xinzhengzhang]

The current zig_library/zig_shared_library used as a library usually still needs to be used with a header file. Can we add an option to add -femit-h?
At the same time, in many scenarios, zig is not only used as an executable binary but also as a dependency for other libraries (like cc_library). Therefore, it would be more convenient to provide CCInfo directly for other cc_library dependencies, rather than requiring the caller to add a CC provider through Aspects.
I'm trying to introduce some zig into my mobile development projects and am interested in exploring the feasibility of this idea.

[xinzhengzhang]

I try to implement some features and ran them in my current iOS project successfully. If the direction is correct, I can continue the pull request.

1. Add option for generate header and exposing CCInfo make it can be directly relied upon by other cc_libraries. in zig_library (The zig_shared_library` has not been implemented yet)
2. Add targets for the apple-related zig toolchain (only tested three iOS targets due to limited devices).

Some issues during the process.

1. If there are compilation errors in the code （zig 0.13.0), -femit-h will cause the error message to be unable to be output and directly crash. Maybe we need to give feedback to Zig?
2. The cross-compiled header files of Zig generated zig.h after -femit-h will have a lot of declaration conflicts with the header files of the corresponding toolchain. Refer to the local_defines in my patch.
3. In zig 0.13.0, ZIG_TARGET_MAX_INT_ALIGNMENT is obtained through the environment during compilation. At present, I have only done hardcode, because all several targets of iOS are 16.

diff --git a/MODULE.bazel b/MODULE.bazel
index 5078a31..ccc6c63 100644
--- a/MODULE.bazel
+++ b/MODULE.bazel
@@ -7,6 +7,7 @@ module(
 bazel_dep(name = "aspect_bazel_lib", version = "2.9.4")
 bazel_dep(name = "bazel_skylib", version = "1.7.1")
 bazel_dep(name = "platforms", version = "0.0.10")
+bazel_dep(name = "apple_support", version = "1.18.0", repo_name = "build_bazel_apple_support")
 
 zig = use_extension("//zig:extensions.bzl", "zig")
 zig.index(file = "//zig/private:versions.json")
diff --git a/zig/private/bzlmod/zig.bzl b/zig/private/bzlmod/zig.bzl
index 979f7a3..3ba4c70 100644
--- a/zig/private/bzlmod/zig.bzl
+++ b/zig/private/bzlmod/zig.bzl
@@ -172,6 +172,7 @@ def _toolchain_extension(module_ctx):
 
     known_versions = merge_version_specs(version_specs)
 
+
     (err, versions) = handle_toolchain_tags(module_ctx.modules, known_versions = known_versions)
 
     if err != None:
diff --git a/zig/private/common/zig_build.bzl b/zig/private/common/zig_build.bzl
index 199bc38..6c3270c 100644
--- a/zig/private/common/zig_build.bzl
+++ b/zig/private/common/zig_build.bzl
@@ -95,6 +95,11 @@ Then you may need to list `@rules_zig//zig/lib:libc` or `@rules_zig//zig/lib:lib
         doc = "Files required by the target during runtime.",
         mandatory = False,
     ),
+    "generate_header": attr.bool(
+        doc = "Whether to generate a header file for the target.",
+        mandatory = False,
+        default = False,
+    ),
     "_settings": attr.label(
         default = "//zig/settings",
         doc = "Zig build settings.",
@@ -158,6 +163,8 @@ def zig_build_impl(ctx, *, kind):
     direct_inputs = []
     transitive_inputs = []
 
+    cc_info = None
+
     zig_collect_data(
         data = ctx.attr.data,
         deps = ctx.attr.deps + ctx.attr.cdeps,
@@ -190,10 +197,66 @@ def zig_build_impl(ctx, *, kind):
         extension = ".lib" if zigtargetinfo.triple.os == "windows" else ".a"
         static = ctx.actions.declare_file(prefix + ctx.label.name + extension)
         outputs.append(static)
-        args.add(static, format = "-femit-bin=%s")
 
+        args.add(static, format = "-femit-bin=%s")
         files = depset([static])
 
+        compilation_context = None
+
+        if ctx.attr.generate_header:
+            header = ctx.actions.declare_file(prefix + ctx.label.name + ".h")
+            outputs.append(header)
+            args.add(header, format = "-femit-h=%s")
+            files = depset([header], transitive = [files])
+
+            header_deps = [f for f in zigtoolchaininfo.zig_files if f.basename == "zig.h"]
+            if (len(header_deps) != 1):
+                fail("Expected exactly one 'zig.h' file in the Zig toolchain files.")
+            standalone_zig_header = header_deps[0]
+            # standalone_zig_header = ctx.actions.declare_file("zig_include/zig.h")
+            # ctx.actions.expand_template(template = header_deps[0], output = standalone_zig_header)
+            # ctx.actions.write(output = standalone_zig_header, content = "#define zig_extern extern\n")
+
+            compilation_context = cc_common.create_compilation_context(
+                headers = depset([header]),
+                direct_public_headers = [header],
+                local_defines = depset([
+                    "_STDLIB_H_", 
+                    "_SYS_MMAN_H_",
+                    "_SYS_FCNTL_H_",
+                    "_UNISTD_H_",
+                    "_USER_SIGNAL_H",
+                    "_SECURE__COMMON_H_",
+                    "_TIME_H_",
+                #     # https://github.com/ziglang/zig/blob/d12123a88cf56428874b359cb63acb8618dfbcfd/src/Type.zig#L1645
+                    # x86_64 and aarch64 are the only targets that require 16-byte alignment.
+                    "ZIG_TARGET_MAX_INT_ALIGNMENT=16"
+                ]),
+                # includes = depset([
+                quote_includes = depset([
+                    header.dirname,
+                    standalone_zig_header.dirname,
+                ]),
+            )
+        libraries_to_link = [
+            cc_common.create_library_to_link(
+                actions = ctx.actions,
+                # alwayslink = True,
+                static_library = static,
+            )
+        ]
+        linker_input = cc_common.create_linker_input(
+            owner = ctx.label,
+            libraries = depset(libraries_to_link),
+        )
+        linking_context = cc_common.create_linking_context(
+            linker_inputs = depset([linker_input]),
+        )
+        cc_info = CcInfo(
+            compilation_context = compilation_context, 
+            linking_context=linking_context
+        )
+
         solib_parents = []
     elif kind == "zig_shared_library":
         prefix = "" if zigtargetinfo.triple.os == "windows" else "lib"
@@ -352,4 +415,7 @@ def zig_build_impl(ctx, *, kind):
         )
         providers.append(run_environment)
 
+    if cc_info:
+        providers.append(cc_info)
+
     return providers
diff --git a/zig/target/BUILD.bazel b/zig/target/BUILD.bazel
index d2be014..fcc8f63 100644
--- a/zig/target/BUILD.bazel
+++ b/zig/target/BUILD.bazel
@@ -1,5 +1,6 @@
 load("//zig:toolchain.bzl", "zig_target_toolchain")
 load("//zig/private:resolved_target_toolchain.bzl", "resolved_target_toolchain")
+load("@build_bazel_apple_support//configs:platforms.bzl", "APPLE_PLATFORMS_CONSTRAINTS")
 
 # This is the Zig target toolchain type. It is used internall within rules_zig
 # to construct the correct set of compiler flags for the current target
@@ -389,6 +390,36 @@ toolchain(
     toolchain_type = ":toolchain_type",
 )
 
+PLATFORMS_IN_APPLE_SUPPORTS = [
+    "ios_arm64",
+    "ios_x86_64",
+    "ios_sim_arm64",
+]
+
+ZIG_PLATFORMS_CONSTRAINTS = {
+    "ios_arm64": "aarch64-ios-none",
+    "ios_x86_64": "x86_64-ios-simulator",
+    "ios_sim_arm64": "aarch64-ios-simulator",
+}
+
+[
+    zig_target_toolchain(
+        name = "apple_support_" + platform,
+        target = ZIG_PLATFORMS_CONSTRAINTS[platform],
+    )
+    for platform in PLATFORMS_IN_APPLE_SUPPORTS
+]
+
+[
+    toolchain(
+        name = "apple_support_" + platform + "_toolchain",
+        target_compatible_with = APPLE_PLATFORMS_CONSTRAINTS[platform],
+        toolchain = "apple_support_" + platform,
+        toolchain_type = ":toolchain_type",
+    )
+    for platform in PLATFORMS_IN_APPLE_SUPPORTS
+]
+
 # Execute `bazel run //util:update_filegroups` to update this target.
 filegroup(
     name = "all_files",

[aherrmann]

Thank you @xinzhengzhang for looking into this! Yes, this is a feature I would like to see in rules_zig, see #14.

The direction sounds reasonable to me.

• Is the generate_header attribute necessary? Are there cases where a user would prefer not to generate the header automatically?
• The zig.h header file should be picked out at the level of the toolchain rule. Repeatedly iterating over all the files in the Zig distribution is a performance issue, and may not work in all cases, e.g. if the header is hidden behind a tree-artifact.
• I wonder if those local defines could perhaps be pulled out into a dedicated target, similar to @rules_zig//zig/lib:libc. That would make it possible to apply appropriate "select"s to ZIG_TARGET_MAX_INT_ALIGNMENT.
• The dependency to rules apple support seems orthogonal to the issue, so I'd prefer to avoid that or discuss it separately to this issue. But, as I understand that's primarily due to the motivating use-case.

[aherrmann]

I started looking into this. I noticed that just blindly adding -femit-h causes the Zig compiler (v0.13.0) to segfault.

$ zig build-lib -femit-h=library.h -Mlibrary=lib.zig
Segmentation fault (core dumped)
$ cat lib.zig
export fn add(a: i32, b: i32) i32 {
    return a + b;
}

I found ziglang/zig#18188, which seems to be related. As stated toward the end, the issue goes way if one also passes -lc. The following succeeds.

$ zig build-lib -lc -femit-bin=liblibrary.a -femit-h=library.h -Mlibrary=lib.zig

This seems to answer the question about always generating headers: No, because we don't always want to pass -lc.

[xinzhengzhang]

Sorry, I lost the message earlier.

Is the generate_header attribute necessary? Are there cases where a user would prefer not to generate the header automatically?
The zig.h header file should be picked out at the level of the toolchain rule. Repeatedly iterating over all the files in the Zig distribution is a performance issue, and may not work in all cases, e.g. if the header is hidden behind a tree-artifact.

In our use case, we mainly serve the use case of Swift/Kotlin. If we can automatically generate headers, then we can more easily and directly complete the cinterop work for Swift and Kotlin/Native, thus making users feel seamless.
But Zig's own generate_header is not well enough, whether it's segfault or those defines that need to avoid cross-compilation. Maybe manually writing a cc_header_library to depend on zig_library is a better solution at present.

The dependency to rules apple support seems orthogonal to the issue, so I'd prefer to avoid that or discuss it separately to this issue. But, as I understand that's primarily due to the motivating use-case.

Of course, we shouldn't make rules_zig depend on the platforms of the Apple world. We should let our own projects register the corresponding toolchain. What we wrote in the diff is just for a simple demonstration.

I found ziglang/zig#18188, which seems to be related. As stated ziglang/zig#18188 (comment), the issue goes way if one also passes -lc. The following succeeds.

My finding is that the types that must be fully exported in Zig code must be a subset of C types, otherwise there will be a segfault. Anything beyond this scope will cause a segfault. For example [*:0]const u8✅ []const u8 ❌. In our practice, we found that it's indeed better to let developers write the header themselves.

---

Thanks very much for the completion of this feature♥️. I also verified it in our project(^HEAD) and found no problems. As for the extension of the auto generation header, we may need to wait for better support from Zig itself.

[aherrmann]

I also verified it in our project(^HEAD) and found no problems.

Thank you for testing this! It's good to hear that it works for your use-case!

As for the extension of the auto generation header, we may need to wait for better support from Zig itself.

I'll still add support to generate the header. Though I'll leave it optional in light of ziglang/zig#18188.

[xinzhengzhang]

Though I'll leave it optional in light of ziglang/zig#18188.

I just tested and found that zig broke in 0.14.0. The bad news is that it even broke -femit-h. The good news is that maybe it has received more attention :(

https://ziglang.org/download/0.14.0/release-notes.html

• [Breaking] As a workaround for #9698, the generated -femit-h header is now never emitted even when the user specifies an override for h_dir. If you absolutely need the emitted header, you now need to do install_artifact.emitted_h = artifact.getEmittedH() until -femit-h is fixed.

[aherrmann]

@xinzhengzhang thank you for the pointer! Indeed, I noticed that Zig 0.14.0 would emit a header despite -femit-h. Digging through the code, this seems to be a relevant change.

I'm puzzled by that release note message. rules_zig is not using the Zig build system abstraction but rather invoking the Zig compiler directly. As of Zig 0.14.0 -femit-h does not emit a header file at all. So, I don't understand how the build system layer is supposed to conjure one later.

Either way, it seems we'll have to wait until header generation is fixed upstream.