Skip to content

Precompiled header handling for zig cc is half-brokenย #22216

Open
@alexrp

Description

@alexrp

This:

zig/src/main.zig

Lines 2654 to 2657 in d48611b

// precompiled header syntax: "zig cc -x c-header test.h -o test.pch"
const emit_pch = ((file_ext == .h or file_ext == .hpp or file_ext == .hm or file_ext == .hmm) and c_out_mode == null);
if (emit_pch)
c_out_mode = .preprocessor;

is not the right way to handle PCHs.

When you type gcc a.c b.h c.h, you get a.out (from a.c), b.h.gch, and c.h.gch.

For Zig, if you type zig cc a.c -x c-header b.h -x c-header c.h, you get a.c.pch, b.h.pch, and c.h.pch! Omitting the -x c-header makes zig cc think you want to link the resulting PCH files and fails as you'd expect.

In other words, the -x should not be necessary; PCH handling should come into effect simply when header files are passed to the compiler. Additionally, compiling PCHs should not preclude compiling a normal binary.

Rather than have PCH handling impact the main compiler mode, I think PCH compilation should be handled as a 'secondary task' similar to the dependency file:

zig/src/Compilation.zig

Lines 5697 to 5699 in d48611b

if (out_dep_path) |p| {
try argv.appendSlice(&[_][]const u8{ "-MD", "-MV", "-MF", p });
}

cc @xxxbxxx (#18600)

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugObserved behavior contradicts documented or intended behaviorzig ccZig as a drop-in C compiler feature

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions