add precompiled c/c++ header support to zig build #17956

xxxbxxx · 2023-11-10T14:41:13Z

It gets my c++ project full rebuild time from

real	10m13.212s
user	139m23.711s
sys	12m1.938s

to

real	4m52.636s
user	64m52.851s
sys	5m59.472s

pch are a little bit different from other compile steps:

like binary object files they are built by the C compiler from a (single) source header file.
however, unlike binary object files, they are not to be fed to the linker, but as a companion source file to subsequent C compiles.

xxxbxxx · 2023-11-24T08:58:33Z

ah. there's a problem still.

somehow didn't notice before but:
when not cleaning the cache and doing a "git pull && build "

I sometimes get this error

:1:1: error: file '/path/to/some_include.h' has been modified since the precompiled header '..../zig-cache/o/1b1f7758f51d4e159b4e5605c9750412/all.pch' was built: mtime changed (was 1700661825, now 1700815558)
:1:1: note: please rebuild precompiled header '..../zig-cache/o/1b1f7758f51d4e159b4e5605c9750412/all.pch'

with some_include.h contents unchanged but probably touched by git or something.

so it needs some adjustment to do either to make llvm less strict, or the zig caching system more strict to accommodate for this.

xxxbxxx · 2023-11-25T08:12:05Z

so it needs some adjustment to do either to make llvm less strict, or the zig caching system more strict to accommodate for this.

There is indeed an option for this:
https://releases.llvm.org/17.0.1/tools/clang/docs/ClangCommandLineReference.html#cmdoption-clang-fpch-validate-input-files-content

andrewrk · 2024-01-15T01:59:25Z

A few points on this topic:

Nice work. I'm willing to merge & maintain this enhancement if you rebase against the latest master and deal with those conflicts.
Is the example from the new standalone test that you added a good representation of how this is intended to be used? If so, I want to run another idea by you: perhaps the build system could do this automatically? Is there any downside? What's stopping the build system from always precompiling headers, caching them, re-running that process if they are invalidated, and always passing pch files to clang?

xxxbxxx · 2024-01-17T08:58:05Z

2. Is the example from the new standalone test that you added a good representation of how this is intended to be used? If so, I want to run another idea by you: perhaps the build system could do this automatically? Is there any downside? What's stopping the build system from always precompiling headers, caching them, re-running that process if they are invalidated, and always passing pch files to clang?

I don't think this would work.

making a unique pch for each compilation unit would be slower, so we'd need to automatically aggreagate includes of multiple c files, to be able to reuse the same pch multiple times
it is sensitive to include order, #defines, ... so it would be tricky to automate this, I think.
you may not want to include every include of the whole program into a single pch, because it turns every touch and build (of a single header) into full rebuild.

What may work is to automatically make a pch header for system/libc/libc++ includes and provide that if none are manually specified. And that could be in the global cache probably.

andrewrk · 2024-01-17T20:33:51Z

Interesting. Thanks for that insight. We can consider that idea regarding libc/libc++ in a separate proposal.

xxxbxxx · 2024-01-21T11:32:58Z

As an other test, I've added pch support to
https://github.com/andrewrk/libchromaprint

patch

diff --git a/build.zig b/build.zig
index e7d4f8e..3774c80 100644
--- a/build.zig
+++ b/build.zig
@@ -18,7 +18,7 @@ pub fn build(b: *std.Build) void {
     lib.linkLibC();
     lib.linkLibCpp();
     lib.addIncludePath(.{ .path = "src" });
-    lib.addConfigHeader(b.addConfigHeader(.{
+    const config_h = b.addConfigHeader(.{
         .style = .{ .cmake = .{ .path = "config.h.in" } },
     }, .{
         .HAVE_ROUND = 1,
@@ -35,7 +35,31 @@ pub fn build(b: *std.Build) void {
         .USE_FFTW3F = null,
         .USE_VDSP = null,
         .USE_KISSFFT = null,
-    }));
+    });
+    const c_flags = &.{
+        "-std=c++11",
+        "-fno-rtti",
+        "-fno-exceptions",
+        "-DHAVE_CONFIG_H",
+        "-D_SCL_SECURE_NO_WARNINGS",
+        "-D__STDC_LIMIT_MACROS",
+        "-D__STDC_CONSTANT_MACROS",
+        "-DCHROMAPRINT_NODLL",
+    };
+    lib.addConfigHeader(config_h);
+
+    const pch = b.addPrecompiledCHeader(.{
+        .name = "chromaprint",
+        .target = target,
+        .optimize = optimize,
+        .cpp_header = true,
+    }, .{
+        .file = .{ .path = "src/pch.h" },
+        .flags = c_flags,
+    });
+    pch.addIncludePath(.{ .path = "src" });
+    pch.addConfigHeader(config_h);
+
     lib.addCSourceFiles(.{
         .files = &.{
             "src/audio_processor.cpp",
@@ -57,16 +81,8 @@ pub fn build(b: *std.Build) void {
             "src/chromaprint.cpp",
             "src/fft_lib_avfft.cpp",
         },
-        .flags = &.{
-            "-std=c++11",
-            "-fno-rtti",
-            "-fno-exceptions",
-            "-DHAVE_CONFIG_H",
-            "-D_SCL_SECURE_NO_WARNINGS",
-            "-D__STDC_LIMIT_MACROS",
-            "-D__STDC_CONSTANT_MACROS",
-            "-DCHROMAPRINT_NODLL",
-        },
+        .flags = c_flags,
+        .precompiled_header = pch,
     });
     lib.addCSourceFiles(.{
         .files = &.{
diff --git a/src/pch.h b/src/pch.h
new file mode 100644
index 0000000..489a7f3
--- /dev/null
+++ b/src/pch.h
@@ -0,0 +1,23 @@
+#include <stdint.h>
+#include <math.h>
+#include <assert.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <vector>
+#include <limits>
+#include <cmath>
+#include <limits>
+#include <algorithm>
+#include <string>
+#include <cstring>
+#include <memory>
+#include <cassert>
+
+extern "C" {
+#include <libavcodec/avcodec.h>
+#include <libavcodec/avfft.h>
+#include <libavutil/mem.h>
+}
+

rebuilding only libchromaprint (and not the dependencies) I get something like:

without .precompiled_header = pch,:

real 0m10.904s
user 0m34.543s
sys 0m6.052s

with .precompiled_header = pch,:

real 0m10.169s
user 0m18.176s
sys 0m4.783s

xxxbxxx · 2024-01-21T11:45:31Z

however there's still something going wrong somewhere.

continuing on the libchromaprint example,
if I:

make some change to src/utils/gaussian_filter.h (like adding whitespace)
then touch src/pch.h
zig build

:1:1: error: file '.../libchromaprint/src/pch.h' has been modified since the precompiled header '.../libchromaprint/zig-cache/o/0a3b415db50f4a754a9af6536bf2a496/chromaprint.pch' was built: mtime changed (was 1705833127, now 1705837082)
:1:1: note: please rebuild precompiled header '.../libchromaprint/zig-cache/o/0a3b415db50f4a754a9af6536bf2a496/chromaprint.pch'

the modified file src/utils/gaussian_filter.h is not included by (or any dependency of) pch.h (it is actually only included by a single cpp file)
So I really don't understand what is going on.

edit: It's much simpler than that.

add whitespace to src/fingerprint_matcher.cpp -> ok
touch src/pch.h, add whitespace to src/fingerprint_matcher.cpp -> error

so it really looks like -fpch-validate-input-files-content doesn't do anything. mmmm.

xxxbxxx · 2024-01-21T12:34:08Z

ok.
apparently it was just that -fpch-validate-input-files-content is needed both when using and when emitting the pch.

lib/std/Build.zig

lib/std/Build/Module.zig

lib/std/Build/Step/Compile.zig

src/main.zig

xxxbxxx · 2024-01-28T01:19:13Z

yeah I was trying to sneak in the feature without add new explicit options, for some reason - probably because precompiled header are specific to c/c++ , not a zig language thing,

I tried to modify the change to be more straight forward, that should address all review comments.

andrewrk · 2024-07-03T19:08:37Z

I'm sorry, I have let this sit too long unreviewed and acquire conflicts. I will fix them for you and attempt to merge this, but I will first give priority to the other PRs that are closer to a mergeable state.

xxxbxxx · 2024-07-06T08:12:05Z

acquire conflicts. I will fix them for you

No trouble: I do use the branch locally and keep it up to date. I just don't push everytime not to waste CI time.. :)

xxxbxxx · 2024-07-06T13:32:11Z

I tried to hack together an example with https://github.com/allyourcodebase/cpython :

You can see it is a bit clumsy to use:

the options need to be repeated. (however I don't see how it can be avoided. for example, adding some mechanism to inherit options from the exe doesn't make sense because the same pch file can be used on multiple exes)
it needs some manual setup, since the include context must be taken into account. see NEEDS_PY_IDENTIFIER
linkLibC() is a bit strange since no linking takes place, but it is needed to add the libc include paths.

However I do observe a small speedup:

	with pch	baseline
real	0m29,353s	0m42,753s
user	4m54,776s	7m50,943s
sys	1m20,702s	1m48,318s

time to rebuild with zig build 5 times.
(only the cpython source, not the openssl dependency. Which I did by hacking a fake config.h option that I change to force a rebuild)

diff --git a/build.zig b/build.zig
index c7fc831039..288e078b96 100644
--- a/build.zig
+++ b/build.zig
@@ -30,7 +30,7 @@ pub fn build(b: *std.Build) void {
     exe.rdynamic = true;
 
     @setEvalBranchQuota(10000);
-    exe.addConfigHeader(b.addConfigHeader(.{
+    const config_header = b.addConfigHeader(.{
         .style = .{ .autoconf = b.path("pyconfig.h.in") },
         .include_path = "pyconfig.h",
     }, .{
@@ -628,7 +628,24 @@ pub fn build(b: *std.Build) void {
         .socklen_t = null,
         .uid_t = null,
         .WORDS_BIGENDIAN = null,
-    }));
+    });
+    exe.addConfigHeader(config_header);
+
+    const precompiled_header = b.addPrecompiledCHeader(.{
+        .name = "Python",
+        .target = target,
+        .optimize = optimize,
+    }, .{ .file = b.path("Include/Python.h"), .flags = &.{
+        "-fwrapv",
+        "-std=c11",
+        "-fvisibility=hidden",
+        "-DPy_BUILD_CORE",
+    } });
+    precompiled_header.linkLibC(); // setup libc include path
+    precompiled_header.addIncludePath(b.path("Include/internal"));
+    precompiled_header.addIncludePath(b.path("."));
+    precompiled_header.addIncludePath(b.path("Include"));
+    precompiled_header.addConfigHeader(config_header);
 
     exe.addCSourceFiles(.{ .files = &.{
         "Modules/_abc.c",
@@ -664,7 +681,6 @@ pub fn build(b: *std.Build) void {
         "Modules/getbuildinfo.c",
         "Modules/itertoolsmodule.c",
         "Modules/main.c",
-        "Modules/mathmodule.c",
         "Modules/md5module.c",
         "Modules/sha1module.c",
         "Modules/sha256module.c",
@@ -805,7 +821,19 @@ pub fn build(b: *std.Build) void {
         "-std=c11",
         "-fvisibility=hidden",
         "-DPy_BUILD_CORE",
+    }, .precompiled_header = precompiled_header.getEmittedBin() });
+
+    // compile without precompiled header:
+    //   the file includes Python.h with NEEDS_PY_IDENTIFIER defined.
+    exe.addCSourceFiles(.{ .files = &.{
+        "Modules/mathmodule.c",
+    }, .flags = &.{
+        "-fwrapv",
+        "-std=c11",
+        "-fvisibility=hidden",
+        "-DPy_BUILD_CORE",
     } });
+
     exe.addCSourceFiles(.{ .files = &.{
         "Modules/getpath.c",
     }, .flags = &.{

xxxbxxx · 2024-09-07T15:58:55Z

(merged back from #20879)

I included a simpler interface to use precompiled headers:

It is now possible to simply add the name of the header file to precompile:

exe.addCSourceFiles(.{
            .files = &.{"file.c", ...},
            .flags = ...,
            .precompiled_header = .{ .source_header = .{.path = b.path("all.h")} },
        });

In order to do this,

I added an extra finalize() function to the build steps,
created new build steps not explicitly requested by the user,
as well as altered the compile steps after the user as initialised them.
I don't know if that fits the general design of the build system or if there's an other way to achieve this.

updated example patch for https://github.com/allyourcodebase/cpython:

--- a/build.zig
+++ b/build.zig
@@ -664,7 +664,6 @@ pub fn build(b: *std.Build) void {
         "Modules/getbuildinfo.c",
         "Modules/itertoolsmodule.c",
         "Modules/main.c",
-        "Modules/mathmodule.c",
         "Modules/md5module.c",
         "Modules/sha1module.c",
         "Modules/sha256module.c",
@@ -805,7 +804,19 @@ pub fn build(b: *std.Build) void {
         "-std=c11",
         "-fvisibility=hidden",
         "-DPy_BUILD_CORE",
-    } });
+    }, .precompiled_header = .{ .source_header = .{ .path = b.path("Include/Python.h") } } });
+
+    // files that includes Python.h with NEEDS_PY_IDENTIFIER defined
+    exe.addCSourceFiles(.{ .files = &.{
+        "Modules/mathmodule.c",
+    }, .flags = &.{
+        "-fwrapv",
+        "-std=c11",
+        "-fvisibility=hidden",
+        "-DPy_BUILD_CORE",
+        "-DNEEDS_PY_IDENTIFIER",
+    }, .precompiled_header = .{ .source_header = .{ .path = b.path("Include/Python.h") } } });
+
     exe.addCSourceFiles(.{ .files = &.{
         "Modules/getpath.c",
     }, .flags = &.{

Time to zig build when altering Include/Python.h:
before:

real 0m8,841s
user 1m33,561s
sys 0m21,765s

after:

real 0m6,969s
user 1m6,623s
sys 0m17,996s

lib/std/Build/Module.zig

GalaxyShard · 2024-11-17T07:51:39Z

lib/std/Build/Module.zig

@@ -46,11 +46,36 @@ pub const RPath = union(enum) {
    special: []const u8,
 };

+// subset of Compilation.FileExt
+pub const AsmSourceLang = enum {


Should there be a way to specify defines and/or flags? When using assembly with the C preprocessor, defines are definitely important; I'm not sure if general purpose flags would be of any use though, and defines are only used in assembly with the C preprocessor.

I guess so, but I never used addAssemblyFile() myself so I don't know how it is used by people. And I don't know if there is a reason to have it separate from addCSourceFile() - which coincidentally also allows for asm files with defines and all.
maybe it should just be removed?

Altough I don't want to include unrelated changes to the pull request, looks like I still felt compelled to add AsmSourceFile to make the API of addAssemblyFile() more similar to addCSourceFile() for some reason, maybe I shouldn't have or I should go all the way. (but that looks like wasted effort if it is to be deleted)

lib/std/Build/Module.zig

GalaxyShard · 2024-11-17T08:13:59Z

lib/std/Build/Module.zig

+    /// "assembler"
+    assembly,
+    /// "assembler-with-cpp"
+    assembly_with_cpp,


If there is already an addAssemblyFile, is .assembly and .assembly_with_cpp necessary in CSourceLang? The only difference is the ability to provide flags and/or defines (which may be important). We probably don't want two ways to do the same thing.

yeah, as I said I'm more drawn to removing it. and maybe finding a better name for addCSourceFile to reflect that it is not "C" source, but "not zig" source?

Relevant comment about the name: #20655 (comment)

Zig primarily has built-in first-class support for the C and C-like languages, and I don't believe there is intention to have that kind of support for other languages, so addCSourceFile may be fine.

GalaxyShard · 2024-11-17T08:14:27Z

lib/std/Build/Step/Compile.zig

+                if (prev_has_xflag and link_object != .c_source_file and link_object != .c_source_files and link_object != .assembly_file) {
+                    try zig_args.append("-x");
+                    try zig_args.append("none");
+                    prev_has_xflag = false;
+                }
+


Is this necessary? It isn't done for cflags and it seems like a bit of a hack.

mmm I don't remember if I was cautious with having a left over "-x option" propagating the rest of the command line, or if there is a actual problem by removing it.
will look into it.

src/main.zig has some relevant information on how the flag is parsed

yeah I reckon if you mix library/objects files and sources
this line .positional => switch (file_ext orelse Compilation.classifyFileExt(mem.sliceTo(it.only_arg, 0))) will propage the -x to unrelated files.
I'll try to make a test case.

(btw, thanks for the review, sorry for the delay)

GalaxyShard · 2024-11-17T08:14:56Z

lib/std/Build/Step/Compile.zig

+                        if (asm_file.lang) |lang| {
+                            try zig_args.append("-x");
+                            try zig_args.append(lang.getLangName());
+                            prev_has_xflag = true;
+                        } else if (prev_has_xflag) {
+                            try zig_args.append("-x");
+                            try zig_args.append("none");
+                            prev_has_xflag = false;
+                        }


This section of code to check the previous -x flag is duplicated 3 times, and the same goes for the check for -cflags. It should probably be refactored.

lib/std/Build/Step/InstallArtifact.zig

lib/std/Build/Step/Compile.zig

lib/std/Build.zig

GalaxyShard · 2024-12-08T19:50:28Z

lib/std/Build/Module.zig

+    /// "assembler"
+    assembly,
+    /// "assembler-with-cpp"
+    assembly_with_cpp,


Relevant comment about the name: #20655 (comment)

Zig primarily has built-in first-class support for the C and C-like languages, and I don't believe there is intention to have that kind of support for other languages, so addCSourceFile may be fine.

GalaxyShard · 2024-12-08T19:58:50Z

lib/std/Build/Step/Compile.zig

@@ -1212,6 +1223,7 @@ fn getZigArgs(compile: *Compile, fuzz: bool) ![][]const u8 {
                        switch (other.kind) {
                            .exe => return step.fail("cannot link with an executable build artifact", .{}),
                            .@"test" => return step.fail("cannot link with a test", .{}),
+                            .pch => @panic("Cannot link with a precompiled header file"),


Any particular reason to use panic instead of step.fail like the two cases above?

GalaxyShard · 2024-12-08T20:09:01Z

lib/std/Build/Step/Compile.zig

@@ -817,17 +824,20 @@ pub fn linkFrameworkWeak(c: *Compile, name: []const u8) void {

 /// Handy when you have many C/C++ source files and want them all to have the same flags.
 pub fn addCSourceFiles(compile: *Compile, options: Module.AddCSourceFilesOptions) void {
+    assert(compile.kind != .pch); // pch can only be generated from a single C header file


I feel it's a bit odd for compile.addCSourceFiles (and the similar functions below) to have different behavior than compile.root_module.addCSourceFiles, especially considering the latter is invalid as well and would probably crash on the assert in finalize. Additionally, it seems most of the functions in Step.Compile don't make much sense for a precompiled header. It may be worth just making a seperate Step.Compile.Pch or Step.PrecompileHeader similar to what Step.TranslateC does.

Additionally, it seems most of the functions in Step.Compile don't make much sense for a precompiled header.

mmm I don't most . The precompiled header are sensitive to most compiler options, so for instance even "linkXXX" functions may change compile flags and defines that impact the header compilation even though the actual linking doesn't take place.

I wouldn't expect any linker options to affect a precompiled header since linking would be done by the executable/library Compile step, although you might know better than I. Also, I can't think of much use for the functions below:

installHeader* addObjCopy checkObject setLinkerScript, setVersionScript // only for the linker forceUndefinedSymbol // for the linker, doesn't really make sense for a pch isDynamicLibrary/isStaticLibrary/isDll/producesPdbFile/producesImplib // always false link* // shouldn't change the output, unless pch's fail to compile when the symbols aren't resolved. addCSourceFile* // can't compile anything more than the pch addWin32ResourceFile setVerboseLink // no linking takes place, therefore no output from the linker getEmitted* // most of these would fail assertions on a pch addObjectFile/addObject

That's a large amount of the user-facing API of Step.Compile which wouldn't make sense to use in this context, I think it's worth having a separate step so that the API makes it more clear on what affects the compilation of the PCH, what is impossible/doesn't make sense, and what doesn't affect compilation.

…tection. and change `addAssemblyFile()` to use a `AsmSourceFile` option struct as well. (breaking change) Language is inferred from the file extension, however: - it can be ambiguous. for instance, ".h" is often used for c headers or c++ headers. ".s" (instead of ".S") assembly files may still need the c preprocessor. (ziglang#20655) - a singular file may be interpreted with different languages depending on the context. in "single-file libraries", the source.h file can be both a c-header to include, or compiled as a C file (with a #define as toggle) (ziglang#19423)

… options in a single compile step. It tests addAssemblyFile() with options, and the CSourceFile .lang override.

…s in Compile step to de-duplicate cflags tracking.

usage example: `zig build-pch -lc++ -x c++-header test.h` `zig run -lc++ -cflags -include-pch test.pch -- main.cpp` It builds the file.pch with llvm "-fpch-validate-input-files-content", so it includes data for better integration with zig caching system.

adds a new mode to the Compile step. It shares most of the code with previous compile steps, but with extra constraints expressed by assert checks.

…led header file.

It is called after the user has fully configured the steps in the build() function.

a compile step to build the pch file will be automatically created. To benefit from precompiled headers, it is now possible to simply change exe.addCSourceFiles(.{ .files = &.{"file.c"}, .flags = ..., }); into exe.addCSourceFiles(.{ .files = &.{"file.c"}, .flags = ..., .precompiled_header = .{ .source_header = .{ path = b.path("rootincludes.h") } }, });

xxxbxxx force-pushed the pch-support branch from d4ed6c7 to 139bff2 Compare November 10, 2023 18:00

xxxbxxx marked this pull request as draft November 24, 2023 08:59

xxxbxxx force-pushed the pch-support branch from 139bff2 to f37ee3f Compare November 25, 2023 08:08

xxxbxxx marked this pull request as ready for review November 25, 2023 08:09

xxxbxxx force-pushed the pch-support branch from f37ee3f to 6b7a99b Compare November 25, 2023 16:28

Vexu mentioned this pull request Dec 22, 2023

Compiling Mold with zig c++ fails, likely due to -x <language> flag #18343

Closed

xxxbxxx mentioned this pull request Jan 17, 2024

zig cc: expose clang precompiled C header support #18600

Merged

xxxbxxx marked this pull request as draft January 17, 2024 08:46

xxxbxxx force-pushed the pch-support branch from 6b7a99b to 7552f89 Compare January 21, 2024 10:03

xxxbxxx force-pushed the pch-support branch from 7552f89 to 12f6a7d Compare January 21, 2024 12:31

xxxbxxx marked this pull request as ready for review January 21, 2024 21:04

andrewrk requested changes Jan 21, 2024

View reviewed changes

xxxbxxx force-pushed the pch-support branch 3 times, most recently from 6ebb133 to 9c51931 Compare January 27, 2024 16:51

xxxbxxx force-pushed the pch-support branch 2 times, most recently from 9b2af04 to b83acd6 Compare January 31, 2024 06:16

xxxbxxx force-pushed the pch-support branch 2 times, most recently from ac05328 to 18f282c Compare April 9, 2024 05:54

xxxbxxx force-pushed the pch-support branch from 18f282c to 97c1419 Compare July 6, 2024 08:07

xxxbxxx mentioned this pull request Jul 22, 2024

Add option to specify language of CSourceFiles #20687

Open

xxxbxxx force-pushed the pch-support branch from 97c1419 to ed01db0 Compare July 24, 2024 13:23

xxxbxxx mentioned this pull request Jul 31, 2024

simpler pch support for zig build #20879

Closed

xxxbxxx force-pushed the pch-support branch from ed01db0 to b9b70ce Compare August 24, 2024 18:02

xxxbxxx force-pushed the pch-support branch from b9b70ce to c025765 Compare September 7, 2024 15:42

xxxbxxx force-pushed the pch-support branch from c025765 to 097a177 Compare September 23, 2024 16:30

kassane mentioned this pull request Sep 24, 2024

Tracking Issues: Zig Upstream kassane/anotherBuildStep#8

Open

22 tasks

GalaxyShard reviewed Nov 17, 2024

View reviewed changes

xxxbxxx force-pushed the pch-support branch from 097a177 to 6ed79a6 Compare December 8, 2024 19:24

GalaxyShard reviewed Dec 8, 2024

View reviewed changes

xxxbxxx force-pushed the pch-support branch from 6ed79a6 to 03b4642 Compare December 10, 2024 21:03

xxxbxxx added 8 commits December 19, 2024 09:00

test: add a standalone test case to test mixing several languages and…

a6b7560

… options in a single compile step. It tests addAssemblyFile() with options, and the CSourceFile .lang override.

std.Build: merge .assembly_file, .c_source_file, .c_source_files case…

761cb7d

…s in Compile step to de-duplicate cflags tracking.

std.Build: add precompiled C header creation

a863f5f

adds a new mode to the Compile step. It shares most of the code with previous compile steps, but with extra constraints expressed by assert checks.

std.Build: add an option to addCSourceFiles() to include a precompi…

47d9aef

…led header file.

std.Build: Add a finalize function to Build.Steps

1dbc006

It is called after the user has fully configured the steps in the build() function.

xxxbxxx marked this pull request as draft December 19, 2024 08:40

xxxbxxx force-pushed the pch-support branch from 03b4642 to 0bd9380 Compare December 19, 2024 08:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add precompiled c/c++ header support to zig build #17956

add precompiled c/c++ header support to zig build #17956

xxxbxxx commented Nov 10, 2023

xxxbxxx commented Nov 24, 2023

xxxbxxx commented Nov 25, 2023

andrewrk commented Jan 15, 2024

xxxbxxx commented Jan 17, 2024

andrewrk commented Jan 17, 2024

xxxbxxx commented Jan 21, 2024

xxxbxxx commented Jan 21, 2024 •

edited

Loading

xxxbxxx commented Jan 21, 2024

xxxbxxx commented Jan 28, 2024

andrewrk commented Jul 3, 2024

xxxbxxx commented Jul 6, 2024

xxxbxxx commented Jul 6, 2024 •

edited

Loading

xxxbxxx commented Sep 7, 2024

GalaxyShard Nov 17, 2024

xxxbxxx Dec 8, 2024

GalaxyShard Nov 17, 2024

xxxbxxx Dec 8, 2024

GalaxyShard Dec 8, 2024

GalaxyShard Nov 17, 2024

xxxbxxx Dec 8, 2024

GalaxyShard Dec 8, 2024

xxxbxxx Dec 8, 2024

GalaxyShard Nov 17, 2024

GalaxyShard Dec 8, 2024

GalaxyShard Dec 8, 2024

GalaxyShard Dec 8, 2024

xxxbxxx Dec 9, 2024

GalaxyShard Dec 10, 2024

add precompiled c/c++ header support to zig build #17956

Are you sure you want to change the base?

add precompiled c/c++ header support to zig build #17956

Conversation

xxxbxxx commented Nov 10, 2023

xxxbxxx commented Nov 24, 2023

xxxbxxx commented Nov 25, 2023

andrewrk commented Jan 15, 2024

xxxbxxx commented Jan 17, 2024

andrewrk commented Jan 17, 2024

xxxbxxx commented Jan 21, 2024

xxxbxxx commented Jan 21, 2024 • edited Loading

xxxbxxx commented Jan 21, 2024

xxxbxxx commented Jan 28, 2024

andrewrk commented Jul 3, 2024

xxxbxxx commented Jul 6, 2024

xxxbxxx commented Jul 6, 2024 • edited Loading

xxxbxxx commented Sep 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xxxbxxx commented Jan 21, 2024 •

edited

Loading

xxxbxxx commented Jul 6, 2024 •

edited

Loading