aboutsummaryrefslogtreecommitdiff
path: root/lib/std/Build/Step/Run.zig
AgeCommit message (Collapse)Author
2025-11-06Step.Run: Fix for `convertPathArg` when cwd and path args are on different ↵Ryan Liptak
drives Fixes #25805
2025-10-30std.Build: fix '--webui' crashMatthew Lugg
Using '--webui' without '--time-report' when there are Run steps in the graph was regressed by https://github.com/ziglang/zig/pull/25029.
2025-10-29std: updating to std.Io interfaceAndrew Kelley
got the build runner compiling
2025-10-18compiler: rename `--test-timeout-ms` to `--test-timeout`Matthew Lugg
The unit can now be specified in the argument.
2025-10-18ci: bump unit test timeoutsmlugg
2025-10-18std.Build: separate errors from failed commandsmlugg
Recording the command in a separate field will give the build runner more freedom to choose how and when the command should be printed.
2025-10-18std.Build.Step.Run: many enhancementsmlugg
This is a major refactor to `Step.Run` which adds new functionality, primarily to the execution of Zig tests. * All tests are run, even if a test crashes. This happens through the same mechanism as timeouts where the test processes is repeatedly respawned as needed. * The build status output is more precise. For each unit test, it differentiates pass, skip, fail, crash, and timeout. Memory leaks are reported separately, as they do not indicate a test's "status", but are rather an additional property (a test with leaks may still pass!). * The number of memory leaks is tracked and reported, both per-test and for a whole `Run` step. * Reporting is made clearer when a step is failed solely due to error logs (`std.log.err`) where every unit test passed.
2025-10-18std.Build: implement unit test timeoutsmlugg
For now, there is a flag to `zig build` called `--test-timeout-ms` which accepts a value in milliseconds. If the execution time of any individual unit test exceeds that number of milliseconds, the test is terminated and marked as timed out. In the future, we may want to increase the granularity of this feature by allowing timeouts to be specified per-step or even per-test. However, a global option is actually very useful. In particular, it can be used in CI scripts to ensure that no individual unit test exceeds some reasonable limit (e.g. 60 seconds) without having to assign limits to every individual test step in the build script. Also, individual unit test durations are now shown in the time report web interface -- this was fairly trivial to add since we're timing tests (to check for timeouts) anyway. This commit makes progress on #19821, but does not close it, because that proposal includes a more sophisticated mechanism for setting timeouts. Co-Authored-By: David Rubin <david@vortan.dev>
2025-09-24fuzzing: implement limited fuzzingLoris Cro
Adds the limit option to `--fuzz=[limit]`. the limit expresses a number of iterations that *each fuzz test* will perform at maximum before exiting. The limit argument supports also 'K', 'M', and 'G' suffixeds (e.g. '10K'). Does not imply `--web-ui` (like unlimited fuzzing does) and prints a fuzzing report at the end. Closes #22900 but does not implement the time based limit, as after internal discussions we concluded to be problematic to both implement and use correctly.
2025-09-19std.Build.Step.Run: Enable passing (generated) file content as argsJustus Klausecker
Adds `addFileContentArg` and `addPrefixedFileContentArg` to pass the content of a file with a lazy path as an argument to a `std.Build.Step.Run`. This enables replicating shell `$()` / cmake `execute_process` with `OUTPUT_VARIABLE` as an input to another `execute_process` in conjuction with `captureStdOut`/`captureStdErr`. To also be able to replicate `$()` automatically trimming trailing newlines and cmake `OUTPUT_STRIP_TRAILING_WHITESPACE`, this patch adds an `options` arg to those functions which allows specifying the desired handling of surrounding whitespace. The `options` arg also allows to specify a custom `basename` for the output. e.g. to add a file extension (concrete use case: Zig `@import()` requires files to have a `.zig`/`.zon` extension to recognize them as valid source files).
2025-08-31std.fmt: delete deprecated APIsAndrew Kelley
std.fmt.Formatter -> std.fmt.Alt std.fmt.format -> std.Io.Writer.print
2025-08-16Build.Step.Run: fix missing stdin buffer and flushIsaac Freund
Writer.sendFileAll() asserts non-zero buffer capacity in the case that the fallback is hit. It also requires the caller to flush. The buffer may be bypassed as an optimization but this is not a guarantee. Also improve the Writer documentation and add an earlier assert on buffer capacity in sendFileAll().
2025-08-16Compilation: remove last instance of deprecatedReaderAndrew Kelley
This also makes initStreaming preemptively disable file size checking.
2025-08-11std.ArrayList: make unmanaged the defaultAndrew Kelley
2025-08-01build system: replace fuzzing UI with build UI, add time reportmlugg
This commit replaces the "fuzzer" UI, previously accessed with the `--fuzz` and `--port` flags, with a more interesting web UI which allows more interactions with the Zig build system. Most notably, it allows accessing the data emitted by a new "time report" system, which allows users to see which parts of Zig programs take the longest to compile. The option to expose the web UI is `--webui`. By default, it will listen on `[::1]` on a random port, but any IPv6 or IPv4 address can be specified with e.g. `--webui=[::1]:8000` or `--webui=127.0.0.1:8000`. The options `--fuzz` and `--time-report` both imply `--webui` if not given. Currently, `--webui` is incompatible with `--watch`; specifying both will cause `zig build` to exit with a fatal error. When the web UI is enabled, the build runner spawns the web server as soon as the configure phase completes. The frontend code consists of one HTML file, one JavaScript file, two CSS files, and a few Zig source files which are built into a WASM blob on-demand -- this is all very similar to the old fuzzer UI. Also inherited from the fuzzer UI is that the build system communicates with web clients over a WebSocket connection. When the build finishes, if `--webui` was passed (i.e. if the web server is running), the build runner does not terminate; it continues running to serve web requests, allowing interactive control of the build system. In the web interface is an overall "status" indicating whether a build is currently running, and also a list of all steps in this build. There are visual indicators (colors and spinners) for in-progress, succeeded, and failed steps. There is a "Rebuild" button which will cause the build system to reset the state of every step (note that this does not affect caching) and evaluate the step graph again. If `--time-report` is passed to `zig build`, a new section of the interface becomes visible, which associates every build step with a "time report". For most steps, this is just a simple "time taken" value. However, for `Compile` steps, the compiler communicates with the build system to provide it with much more interesting information: time taken for various pipeline phases, with a per-declaration and per-file breakdown, sorted by slowest declarations/files first. This feature is still in its early stages: the data can be a little tricky to understand, and there is no way to, for instance, sort by different properties, or filter to certain files. However, it has already given us some interesting statistics, and can be useful for spotting, for instance, particularly complex and slow compile-time logic. Additionally, if a compilation uses LLVM, its time report includes the "LLVM pass timing" information, which was previously accessible with the (now removed) `-ftime-report` compiler flag. To make time reports more useful, ZIR and compilation caches are ignored by the Zig compiler when they are enabled -- in other words, `Compile` steps *always* run, even if their result should be cached. This means that the flag can be used to analyze a project's compile time without having to repeatedly clear cache directory, for instance. However, when using `-fincremental`, updates other than the first will only show you the statistics for what changed on that particular update. Notably, this gives us a fairly nice way to see exactly which declarations were re-analyzed by an incremental update. If `--fuzz` is passed to `zig build`, another section of the web interface becomes visible, this time exposing the fuzzer. This is quite similar to the fuzzer UI this commit replaces, with only a few cosmetic tweaks. The interface is closer than before to supporting multiple fuzz steps at a time (in line with the overall strategy for this build UI, the goal will be for all of the fuzz steps to be accessible in the same interface), but still doesn't actually support it. The fuzzer UI looks quite different under the hood: as a result, various bugs are fixed, although other bugs remain. For instance, viewing the source code of any file other than the root of the main module is completely broken (as on master) due to some bogus file-to-module assignment logic in the fuzzer UI. Implementation notes: * The `lib/build-web/` directory holds the client side of the web UI. * The general server logic is in `std.Build.WebServer`. * Fuzzing-specific logic is in `std.Build.Fuzz`. * `std.Build.abi` is the new home of `std.Build.Fuzz.abi`, since it now relates to the build system web UI in general. * The build runner now has an **actual** general-purpose allocator, because thanks to `--watch` and `--webui`, the process can be arbitrarily long-lived. The gpa is `std.heap.DebugAllocator`, but the arena remains backed by `std.heap.page_allocator` for efficiency. I fixed several crashes caused by conflation of `gpa` and `arena` in the build runner and `std.Build`, but there may still be some I have missed. * The I/O logic in `std.Build.WebServer` is pretty gnarly; there are a *lot* of threads involved. I anticipate this situation improving significantly once the `std.Io` interface (with concurrency support) is introduced.
2025-07-30build system: print captured stderr on Run step failureLoris Cro
when a Run step that captures stderr fails, no output from it is visible by the user and, since the step failed, any downstream step that would process the captured stream will not run, making it impossible for the user to see the stderr output from the failed process invocation, which makes for a frustrating puzzle when this happens in CI.
2025-07-23std.Io.poll: update to new I/O APIAndrew Kelley
2025-07-21std.fs.File: delete writeFileAll and friendsAndrew Kelley
please use File.Writer for these use cases also breaking API changes to std.fs.AtomicFile
2025-07-20Merge pull request #24488 from ziglang/moreAndrew Kelley
std.zig: finish updating to new I/O API
2025-07-20std.Build.Step.Run: fix up 681d324c49e7cdc773cc891ea49ed69dd03c23c7Alex Rønne Petersen
https://github.com/ziglang/zig/pull/24151/files#r2217494741
2025-07-19std.Io.Writer: fix writeSliceSwapAndrew Kelley
tried to be too clever, wrote bad code
2025-07-12std.Build.Step.Run: Set WINEDEBUG=-all for -fwine by default.Alex Rønne Petersen
This silences the excessive default stderr logging from Wine. The user can still override this by setting WINEDEBUG in the environment; this just provides a more sensible default. Closes #24139.
2025-07-07std.fmt: breaking API changesAndrew Kelley
added adapter to AnyWriter and GenericWriter to help bridge the gap between old and new API make std.testing.expectFmt work at compile-time std.fmt no longer has a dependency on std.unicode. Formatted printing was never properly unicode-aware. Now it no longer pretends to be. Breakage/deprecations: * std.fs.File.reader -> std.fs.File.deprecatedReader * std.fs.File.writer -> std.fs.File.deprecatedWriter * std.io.GenericReader -> std.io.Reader * std.io.GenericWriter -> std.io.Writer * std.io.AnyReader -> std.io.Reader * std.io.AnyWriter -> std.io.Writer * std.fmt.format -> std.fmt.deprecatedFormat * std.fmt.fmtSliceEscapeLower -> std.ascii.hexEscape * std.fmt.fmtSliceEscapeUpper -> std.ascii.hexEscape * std.fmt.fmtSliceHexLower -> {x} * std.fmt.fmtSliceHexUpper -> {X} * std.fmt.fmtIntSizeDec -> {B} * std.fmt.fmtIntSizeBin -> {Bi} * std.fmt.fmtDuration -> {D} * std.fmt.fmtDurationSigned -> {D} * {} -> {f} when there is a format method * format method signature - anytype -> *std.io.Writer - inferred error set -> error{WriteFailed} - options -> (deleted) * std.fmt.Formatted - now takes context type explicitly - no fmt string
2025-06-20Merge pull request #24227 from mlugg/misc-build-stuffMatthew Lugg
`std.Build`: more miscellaneous bits
2025-06-20std.Build.Step.Run: pass correct relative cache dir to testsmlugg
Fixes an additional bug reported in the closed #24216.
2025-06-19Target: pass and use locals by pointer instead of by valueJacob Young
This struct is larger than 256 bytes and code that copies it consistently shows up in profiles of the compiler.
2025-06-19Build: add install commands to `--verbose` outputJacob Young
2025-06-18std.Build.Step.Run: prefix relative path arguments with './'mlugg
This is necessary in two cases: * On POSIX, the exe path (`argv[0]`) must contain a path separator * Some programs might treat a file named e.g. `-foo` as a flag, which can be avoided by passing `./-foo` Rather than detecting these two cases, just always include the prefix; there's no harm in it. Also, if the cwd is specified, include it in the manifest. If the user has set the cwd of a Run step, it is clearly because this affects the behavior of the executable somehow, so that cwd path should be a part of the step's manifest. Resolves: #24216
2025-06-13std.Build.Step.Run: convert relative paths to be relative to child cwdmlugg
Because any `LazyPath` might be resolved to a relative path, it's incorrect to pass that directly to a child process whose cwd might differ. Instead, if the child has an overriden cwd, we need to convert such paths to be relative to the child cwd using `std.fs.path.relative`.
2025-06-09std.Build.Step.Run: add addDecoratedDirectoryArg functionAndrew Kelley
For directory arguments that need both prefix and suffix strings appended. Needed to unbreak ffmpeg package after fe855691f6f742a14678cb617422977c2a55be39
2025-05-21std.Build.Step.Run: inherit build runner cwdmlugg
Right now, if you override the build root with `--build-root`, then `Run` steps can fail to execute because of incorrect path handling in the compiler: `std.process.Child` gets a cwd-relative path, but also has its cwd set to the build root. The latter behavior is really weird; it doesn't match my expectations, nor does it match how we spawn child `zig` processes. So, this commit makes the child process inherit the build runner's cwd, as `LazyPath.getPath2` *expects* it to. After investigating, this behavior dates all the way back to 2017; it was introduced in 4543413. So, there isn't any clear/documented reason for this; it should be safe to revert, since under the modern `LazyPath` system it is strictly a bug AFAICT.
2025-05-06std.Build: Rename --glibc-runtimes to --libc-runtimes and enable it for musl.Alex Rønne Petersen
2025-03-26zig build: add env_map entries to hash for Step.Rundweiller
This change fixes false-positive cache hits for run steps that get run with different sets of environment variables due the the environment map being excluded from the cache hash.
2025-01-20std.process.Child: add `waitForSpawn`mlugg
`std.Build.Step.Run` makes the very reasonable assumption that `error.InvalidExe` will be reported on `spawn` if it will happen. However, this property does not currently hold on POSIX targets. This is, through a slightly convoluted series of events, partially responsible for the sporadic `BrokenPipe` errors we've been seeing more and more in CI runs. Making `spawn` wait for the child to exec in the POSIX path introduces a block of up to 400us. So, instead of doing that, we add a new API for this particular case: `waitForSpawn`. This function is a nop on Windows, but on POSIX it blocks until the child successfully (or otherwise) calls `execvpe`, and reports the error if necessary. `std.Build.Step.Run` calls this function, so that it can get `error.InvalidExe` when it wants it. I'm not convinced that this API is optimal. However, I think this entire API needs to be either heavily refactored or straight-up redesigned (related: #22504), so I'm not too worried about hitting the perfect API: I'd rather just fix this bug for now, and figure out the long-term goal a bit later.
2024-12-18std.Build: simplify module dependency handlingmlugg
At the expense of a slight special case in the build runner, we can make the handling of dependencies between modules a little shorter and much easier to follow. When module and step graphs are being constructed during the "configure" phase, we do not set up step dependencies triggered by modules. Instead, after the configure phase, the build runner traverses the whole step/module graph, starting from the root top-level steps, and configures all step dependencies implied by modules. The "make" phase then proceeds as normal. Also, the old `Module.dependencyIterator` logic is replaced by two separate iterables. `Module.getGraph` takes the root module of a compilation, and returns all modules in its graph; while `Step.Compile.getCompileDependencies` takes a `*Step.Compile` and returns all `*Step.Compile` it depends on, recursively, possibly excluding dynamic libraries. The old `Module.dependencyIterator` combined these two functions into one unintuitive iterator; they are now separated, which in particular helps readability at the usage sites which only need one or the other.
2024-12-18std.Build.Step.Compile: change `root_module` field type to `*Module`mlugg
This commit changes the `root_module` field of `std.Build.Step.Compile` to be a `*Module` rather than a `Module`. This is a breaking change, but an incredibly minor one (the full potential extent of the breakage can be seen in the modified standalone test). This change will be necessary for an upcoming improvement, so it was convenient to make it here.
2024-12-18std.Build: remove deprecated APIsEric Joldasov
These APIs were all deprecated prior to the release of 0.13.0, so can be safety removed in the current release cycle. `std.Build`: * `host` -> `graph.host` `std.Build.Step.Compile`: * `setLinkerScriptPath` -> `setLinkerScript` * `defineCMacro` -> `root_module.addCMacro` * `linkFrameworkNeeded`-> `root_module.linkFramework` * `linkFrameworkWeak`-> `root_module.linkFramework` `std.Build.Step.ObjCopy`: * `getOutputSource` -> `getOutput` `std.Build.Step.Options`: * `addOptionArtifact` -> `addOptionPath` * `getSource` -> `getOutput` `std.Build.Step.Run`: * `extra_file_dependencies` -> `addFileInput` * `addDirectorySourceArg` -> `addDirectoryArg` * `addPrefixedDirectorySourceArg` -> `addPrefixedDirectoryArg`
2024-11-28std.Build.Step.Run: Use std.zig.target.glibcRuntimeTriple() in runCommand().Alex Rønne Petersen
2024-11-27std.Build: gracefully handle child stdin closing when running testsmlugg
We have deduced that it seems the sporadic BrokenPipe failures happening on the CI runners (e.g. https://github.com/ziglang/zig/actions/runs/12035916948/job/33555963190) are likely caused by the test runner's stdin pipe abnormally closing, likely due to the process crashing. Here, we introduce error handling for this case, so that if these writes fail, the step is marked as failed correctly, and we still collect the child's stderr to report. This won't fix the CI issues, but it should promote them to proper error messages including child stderr, which -- at least in theory -- should allow us to ultimately track down where the errors come from. Note that this change is desirable regardless of bugs in the test runner or similar, since the child process could terminate abnormally for any number of reasons (e.g. a crashing test), and such cases should be correctly reported by the build runner.
2024-11-26diversify "unable to spawn" failure messagesAndrew Kelley
to help understand where a spurious failure is occurring
2024-11-19build: don't hang when capturing Stdout of verbose Build.Step.RunAlex Kladov
When using Build.Step.Run.captureStdOut with a program that prints more than 10 megabytes of output, the build process hangs. This is because evalGeneric returns an error without reading child's stdin till the end, so we subsequently get stuck in `try child.wait()`. To fix this, make sure to kill the child in case of an error! Output before this change: λ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 [3/8] steps └─ run gh ^C λ # an hour of debugging Output after this change: λ ./zig/zig build -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6 install └─ install generated to ../tigerbeetle └─ run build_mutliversion (tigerbeetle) └─ run unzip └─ run gh failure error: unable to spawn gh: StdoutStreamTooLong Build Summary: 3/8 steps succeeded; 1 failed (disable with --summary none) install transitive failure └─ install generated to ../tigerbeetle transitive failure └─ run build_mutliversion (tigerbeetle) transitive failure └─ run unzip transitive failure └─ run gh failure error: the following build command failed with exit code 1: /home/matklad/p/tb/work/.zig-cache/o/c0e3f5e66ff441cd16f9a1a7e1401494/build /home/matklad/p/tb/work/zig/zig /home/matklad/p/tb/work /home/matklad/p/tb/work/.zig-cache /home/matklad/.cache/zig --seed 0xc1d4efc8 -Zaecc61299ff08765 -Dmultiversion=0.15.6 -Dconfig-release=0.15.7 -Dconfig-release-client-min=0.15.6
2024-09-12Replace deprecated default initializations with decl literalsLinus Groh
2024-08-28std: update `std.builtin.Type` fields to follow naming conventionsmlugg
The compiler actually doesn't need any functional changes for this: Sema does reification based on the tag indices of `std.builtin.Type` already! So, no zig1.wasm update is necessary. This change is necessary to disallow name clashes between fields and decls on a type, which is a prerequisite of #9938.
2024-08-19fix various issues related to Path handling in the compiler and stdRobin Voetter
A compilation build step for which the binary is not required could not be compiled previously. There were 2 issues that caused this: - The compiler communicated only the results of the emitted binary and did not properly communicate the result if the binary was not emitted. This is fixed by communicating the final hash of the artifact path (the hash of the corresponding /o/<hash> directory) and communicating this instead of the entire path. This changes the zig build --listen protocol to communicate hashes instead of paths, and emit_bin_path is accordingly renamed to emit_digest. - There was an error related to the default llvm object path when CacheUse.Whole was selected. I'm not really sure why this didn't manifest when the binary is also emitted. This was fixed by improving the path handling related to flush() and emitLlvmObject(). In general, this commit also improves some of the path handling throughout the compiler and standard library.
2024-08-07fuzzer web ui: introduce entry pointsAndrew Kelley
so you can have somewhere to start browsing
2024-08-07fuzzing: progress towards web UIAndrew Kelley
* libfuzzer: close file after mmap * fuzzer/main.js: connect with EventSource and debug dump the messages. currently this prints how many fuzzer runs have been attempted to console.log. * extract some `std.debug.Info` logic into `std.debug.Coverage`. Prepares for consolidation across multiple different executables which share source files, and makes it possible to send all the PC/SourceLocation mapping data with 4 memcpy'd arrays. * std.Build.Fuzz: - spawn a thread to watch the message queue and signal event subscribers. - track coverage map data - respond to /events URL with EventSource messages on a timer
2024-08-07introduce a web interface for fuzzingAndrew Kelley
* new .zig-cache subdirectory: 'v' - stores coverage information with filename of hash of PCs that want coverage. This hash is a hex encoding of the 64-bit coverage ID. * build runner * fixed bug in file system inputs when a compile step has an overridden zig_lib_dir field set. * set some std lib options optimized for the build runner - no side channel mitigations - no Transport Layer Security - no crypto fork safety * add a --port CLI arg for choosing the port the fuzzing web interface listens on. it defaults to choosing a random open port. * introduce a web server, and serve a basic single page application - shares wasm code with autodocs - assets are created live on request, for convenient development experience. main.wasm is properly cached if nothing changes. - sources.tar comes from file system inputs (introduced with the `--watch` feature) * receives coverage ID from test runner and sends it on a thread-safe queue to the WebServer. * test runner - takes a zig cache directory argument now, for where to put coverage information. - sends coverage ID to parent process * fuzzer - puts its logs (in debug mode) in .zig-cache/tmp/libfuzzer.log - computes coverage_id and makes it available with `fuzzer_coverage_id` exported function. - the memory-mapped coverage file is now namespaced by the coverage id in hex encoding, in `.zig-cache/v` * tokenizer - add a fuzz test to check that several properties are upheld
2024-07-25add --debug-rt CLI arg to the compiler + bonus editsAndrew Kelley
The flag makes compiler_rt and libfuzzer be in debug mode. Also: * fuzzer: override debug logs and disable debug logs for frequently called functions * std.Build.Fuzz: fix bug of rerunning the old unit test binary * report errors from rebuilding the unit tests better * link.Elf: additionally add tsan lib and fuzzer lib to the hash
2024-07-25build runner sends a start_fuzzing message to test runnerAndrew Kelley
2024-07-25build runner: extract logic to std.Build.FuzzAndrew Kelley