commit
00d2cf3c69
6 changed files with 332 additions and 0 deletions
@ -0,0 +1,156 @@
|
||||
const std = @import("std"); |
||||
|
||||
// Although this function looks imperative, it does not perform the build |
||||
// directly and instead it mutates the build graph (`b`) that will be then |
||||
// executed by an external runner. The functions in `std.Build` implement a DSL |
||||
// for defining build steps and express dependencies between them, allowing the |
||||
// build runner to parallelize the build automatically (and the cache system to |
||||
// know when a step doesn't need to be re-run). |
||||
pub fn build(b: *std.Build) void { |
||||
// Standard target options allow the person running `zig build` to choose |
||||
// what target to build for. Here we do not override the defaults, which |
||||
// means any target is allowed, and the default is native. Other options |
||||
// for restricting supported target set are available. |
||||
const target = b.standardTargetOptions(.{}); |
||||
// Standard optimization options allow the person running `zig build` to select |
||||
// between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. Here we do not |
||||
// set a preferred release mode, allowing the user to decide how to optimize. |
||||
const optimize = b.standardOptimizeOption(.{}); |
||||
// It's also possible to define more custom flags to toggle optional features |
||||
// of this build script using `b.option()`. All defined flags (including |
||||
// target and optimize options) will be listed when running `zig build --help` |
||||
// in this directory. |
||||
|
||||
// This creates a module, which represents a collection of source files alongside |
||||
// some compilation options, such as optimization mode and linked system libraries. |
||||
// Zig modules are the preferred way of making Zig code available to consumers. |
||||
// addModule defines a module that we intend to make available for importing |
||||
// to our consumers. We must give it a name because a Zig package can expose |
||||
// multiple modules and consumers will need to be able to specify which |
||||
// module they want to access. |
||||
const mod = b.addModule("zigeru", .{ |
||||
// The root source file is the "entry point" of this module. Users of |
||||
// this module will only be able to access public declarations contained |
||||
// in this file, which means that if you have declarations that you |
||||
// intend to expose to consumers that were defined in other files part |
||||
// of this module, you will have to make sure to re-export them from |
||||
// the root file. |
||||
.root_source_file = b.path("src/root.zig"), |
||||
// Later on we'll use this module as the root module of a test executable |
||||
// which requires us to specify a target. |
||||
.target = target, |
||||
}); |
||||
|
||||
// Here we define an executable. An executable needs to have a root module |
||||
// which needs to expose a `main` function. While we could add a main function |
||||
// to the module defined above, it's sometimes preferable to split business |
||||
// logic and the CLI into two separate modules. |
||||
// |
||||
// If your goal is to create a Zig library for others to use, consider if |
||||
// it might benefit from also exposing a CLI tool. A parser library for a |
||||
// data serialization format could also bundle a CLI syntax checker, for example. |
||||
// |
||||
// If instead your goal is to create an executable, consider if users might |
||||
// be interested in also being able to embed the core functionality of your |
||||
// program in their own executable in order to avoid the overhead involved in |
||||
// subprocessing your CLI tool. |
||||
// |
||||
// If neither case applies to you, feel free to delete the declaration you |
||||
// don't need and to put everything under a single module. |
||||
const exe = b.addExecutable(.{ |
||||
.name = "zigeru", |
||||
.root_module = b.createModule(.{ |
||||
// b.createModule defines a new module just like b.addModule but, |
||||
// unlike b.addModule, it does not expose the module to consumers of |
||||
// this package, which is why in this case we don't have to give it a name. |
||||
.root_source_file = b.path("src/main.zig"), |
||||
// Target and optimization levels must be explicitly wired in when |
||||
// defining an executable or library (in the root module), and you |
||||
// can also hardcode a specific target for an executable or library |
||||
// definition if desireable (e.g. firmware for embedded devices). |
||||
.target = target, |
||||
.optimize = optimize, |
||||
// List of modules available for import in source files part of the |
||||
// root module. |
||||
.imports = &.{ |
||||
// Here "zigeru" is the name you will use in your source code to |
||||
// import this module (e.g. `@import("zigeru")`). The name is |
||||
// repeated because you are allowed to rename your imports, which |
||||
// can be extremely useful in case of collisions (which can happen |
||||
// importing modules from different packages). |
||||
.{ .name = "zigeru", .module = mod }, |
||||
}, |
||||
}), |
||||
}); |
||||
|
||||
// This declares intent for the executable to be installed into the |
||||
// install prefix when running `zig build` (i.e. when executing the default |
||||
// step). By default the install prefix is `zig-out/` but can be overridden |
||||
// by passing `--prefix` or `-p`. |
||||
b.installArtifact(exe); |
||||
|
||||
// This creates a top level step. Top level steps have a name and can be |
||||
// invoked by name when running `zig build` (e.g. `zig build run`). |
||||
// This will evaluate the `run` step rather than the default step. |
||||
// For a top level step to actually do something, it must depend on other |
||||
// steps (e.g. a Run step, as we will see in a moment). |
||||
const run_step = b.step("run", "Run the app"); |
||||
|
||||
// This creates a RunArtifact step in the build graph. A RunArtifact step |
||||
// invokes an executable compiled by Zig. Steps will only be executed by the |
||||
// runner if invoked directly by the user (in the case of top level steps) |
||||
// or if another step depends on it, so it's up to you to define when and |
||||
// how this Run step will be executed. In our case we want to run it when |
||||
// the user runs `zig build run`, so we create a dependency link. |
||||
const run_cmd = b.addRunArtifact(exe); |
||||
run_step.dependOn(&run_cmd.step); |
||||
|
||||
// By making the run step depend on the default step, it will be run from the |
||||
// installation directory rather than directly from within the cache directory. |
||||
run_cmd.step.dependOn(b.getInstallStep()); |
||||
|
||||
// This allows the user to pass arguments to the application in the build |
||||
// command itself, like this: `zig build run -- arg1 arg2 etc` |
||||
if (b.args) |args| { |
||||
run_cmd.addArgs(args); |
||||
} |
||||
|
||||
// Creates an executable that will run `test` blocks from the provided module. |
||||
// Here `mod` needs to define a target, which is why earlier we made sure to |
||||
// set the releative field. |
||||
const mod_tests = b.addTest(.{ |
||||
.root_module = mod, |
||||
}); |
||||
|
||||
// A run step that will run the test executable. |
||||
const run_mod_tests = b.addRunArtifact(mod_tests); |
||||
|
||||
// Creates an executable that will run `test` blocks from the executable's |
||||
// root module. Note that test executables only test one module at a time, |
||||
// hence why we have to create two separate ones. |
||||
const exe_tests = b.addTest(.{ |
||||
.root_module = exe.root_module, |
||||
}); |
||||
|
||||
// A run step that will run the second test executable. |
||||
const run_exe_tests = b.addRunArtifact(exe_tests); |
||||
|
||||
// A top level step for running all tests. dependOn can be called multiple |
||||
// times and since the two run steps do not depend on one another, this will |
||||
// make the two of them run in parallel. |
||||
const test_step = b.step("test", "Run tests"); |
||||
test_step.dependOn(&run_mod_tests.step); |
||||
test_step.dependOn(&run_exe_tests.step); |
||||
|
||||
// Just like flags, top level steps are also listed in the `--help` menu. |
||||
// |
||||
// The Zig build system is entirely implemented in userland, which means |
||||
// that it cannot hook into private compiler APIs. All compilation work |
||||
// orchestrated by the build system will result in other Zig compiler |
||||
// subcommands being invoked with the right flags defined. You can observe |
||||
// these invocations when one fails (or you pass a flag to increase |
||||
// verbosity) to validate assumptions and diagnose problems. |
||||
// |
||||
// Lastly, the Zig build system is relatively simple and self-contained, |
||||
// and reading its source code will allow you to master it. |
||||
} |
||||
@ -0,0 +1,81 @@
|
||||
.{ |
||||
// This is the default name used by packages depending on this one. For |
||||
// example, when a user runs `zig fetch --save <url>`, this field is used |
||||
// as the key in the `dependencies` table. Although the user can choose a |
||||
// different name, most users will stick with this provided value. |
||||
// |
||||
// It is redundant to include "zig" in this name because it is already |
||||
// within the Zig package namespace. |
||||
.name = .zigeru, |
||||
// This is a [Semantic Version](https://semver.org/). |
||||
// In a future version of Zig it will be used for package deduplication. |
||||
.version = "0.0.0", |
||||
// Together with name, this represents a globally unique package |
||||
// identifier. This field is generated by the Zig toolchain when the |
||||
// package is first created, and then *never changes*. This allows |
||||
// unambiguous detection of one package being an updated version of |
||||
// another. |
||||
// |
||||
// When forking a Zig project, this id should be regenerated (delete the |
||||
// field and run `zig build`) if the upstream project is still maintained. |
||||
// Otherwise, the fork is *hostile*, attempting to take control over the |
||||
// original project's identity. Thus it is recommended to leave the comment |
||||
// on the following line intact, so that it shows up in code reviews that |
||||
// modify the field. |
||||
.fingerprint = 0x5ad2c28ec99c9a84, // Changing this has security and trust implications. |
||||
// Tracks the earliest Zig version that the package considers to be a |
||||
// supported use case. |
||||
.minimum_zig_version = "0.15.2", |
||||
// This field is optional. |
||||
// Each dependency must either provide a `url` and `hash`, or a `path`. |
||||
// `zig build --fetch` can be used to fetch all dependencies of a package, recursively. |
||||
// Once all dependencies are fetched, `zig build` no longer requires |
||||
// internet connectivity. |
||||
.dependencies = .{ |
||||
// See `zig fetch --save <url>` for a command-line interface for adding dependencies. |
||||
//.example = .{ |
||||
// // When updating this field to a new URL, be sure to delete the corresponding |
||||
// // `hash`, otherwise you are communicating that you expect to find the old hash at |
||||
// // the new URL. If the contents of a URL change this will result in a hash mismatch |
||||
// // which will prevent zig from using it. |
||||
// .url = "https://example.com/foo.tar.gz", |
||||
// |
||||
// // This is computed from the file contents of the directory of files that is |
||||
// // obtained after fetching `url` and applying the inclusion rules given by |
||||
// // `paths`. |
||||
// // |
||||
// // This field is the source of truth; packages do not come from a `url`; they |
||||
// // come from a `hash`. `url` is just one of many possible mirrors for how to |
||||
// // obtain a package matching this `hash`. |
||||
// // |
||||
// // Uses the [multihash](https://multiformats.io/multihash/) format. |
||||
// .hash = "...", |
||||
// |
||||
// // When this is provided, the package is found in a directory relative to the |
||||
// // build root. In this case the package's hash is irrelevant and therefore not |
||||
// // computed. This field and `url` are mutually exclusive. |
||||
// .path = "foo", |
||||
// |
||||
// // When this is set to `true`, a package is declared to be lazily |
||||
// // fetched. This makes the dependency only get fetched if it is |
||||
// // actually used. |
||||
// .lazy = false, |
||||
//}, |
||||
}, |
||||
// Specifies the set of files and directories that are included in this package. |
||||
// Only files and directories listed here are included in the `hash` that |
||||
// is computed for this package. Only files listed here will remain on disk |
||||
// when using the zig package manager. As a rule of thumb, one should list |
||||
// files required for compilation plus any license(s). |
||||
// Paths are relative to the build root. Use the empty string (`""`) to refer to |
||||
// the build root itself. |
||||
// A directory listed here means that all files within, recursively, are included. |
||||
.paths = .{ |
||||
"build.zig", |
||||
"build.zig.zon", |
||||
"src", |
||||
// For example... |
||||
//"LICENSE", |
||||
//"README.md", |
||||
}, |
||||
} |
||||
@ -0,0 +1,27 @@
|
||||
{ |
||||
"nodes": { |
||||
"nixpkgs": { |
||||
"locked": { |
||||
"lastModified": 1761373498, |
||||
"narHash": "sha256-Q/uhWNvd7V7k1H1ZPMy/vkx3F8C13ZcdrKjO7Jv7v0c=", |
||||
"owner": "nixos", |
||||
"repo": "nixpkgs", |
||||
"rev": "6a08e6bb4e46ff7fcbb53d409b253f6bad8a28ce", |
||||
"type": "github" |
||||
}, |
||||
"original": { |
||||
"owner": "nixos", |
||||
"ref": "nixos-unstable", |
||||
"repo": "nixpkgs", |
||||
"type": "github" |
||||
} |
||||
}, |
||||
"root": { |
||||
"inputs": { |
||||
"nixpkgs": "nixpkgs" |
||||
} |
||||
} |
||||
}, |
||||
"root": "root", |
||||
"version": 7 |
||||
} |
||||
@ -0,0 +1,18 @@
|
||||
{ |
||||
description = "ziglings"; |
||||
|
||||
inputs = { |
||||
nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable"; |
||||
}; |
||||
|
||||
outputs = { self, nixpkgs }: |
||||
let |
||||
pkgs = nixpkgs.legacyPackages.x86_64-linux; |
||||
in { |
||||
devShells.x86_64-linux.default = pkgs.mkShell { |
||||
buildInputs = [ |
||||
pkgs.zig |
||||
]; |
||||
}; |
||||
}; |
||||
} |
||||
@ -0,0 +1,27 @@
|
||||
const std = @import("std"); |
||||
const zigeru = @import("zigeru"); |
||||
|
||||
pub fn main() !void { |
||||
// Prints to stderr, ignoring potential errors. |
||||
std.debug.print("All your {s} are belong to us.\n", .{"codebase"}); |
||||
try zigeru.bufferedPrint(); |
||||
} |
||||
|
||||
test "simple test" { |
||||
const gpa = std.testing.allocator; |
||||
var list: std.ArrayList(i32) = .empty; |
||||
defer list.deinit(gpa); // Try commenting this out and see if zig detects the memory leak! |
||||
try list.append(gpa, 42); |
||||
try std.testing.expectEqual(@as(i32, 42), list.pop()); |
||||
} |
||||
|
||||
test "fuzz example" { |
||||
const Context = struct { |
||||
fn testOne(context: @This(), input: []const u8) anyerror!void { |
||||
_ = context; |
||||
// Try passing `--fuzz` to `zig build test` and see if it manages to fail this test case! |
||||
try std.testing.expect(!std.mem.eql(u8, "canyoufindme", input)); |
||||
} |
||||
}; |
||||
try std.testing.fuzz(Context{}, Context.testOne, .{}); |
||||
} |
||||
@ -0,0 +1,23 @@
|
||||
//! By convention, root.zig is the root source file when making a library. |
||||
const std = @import("std"); |
||||
|
||||
pub fn bufferedPrint() !void { |
||||
// Stdout is for the actual output of your application, for example if you |
||||
// are implementing gzip, then only the compressed bytes should be sent to |
||||
// stdout, not any debugging messages. |
||||
var stdout_buffer: [1024]u8 = undefined; |
||||
var stdout_writer = std.fs.File.stdout().writer(&stdout_buffer); |
||||
const stdout = &stdout_writer.interface; |
||||
|
||||
try stdout.print("Run `zig build test` to run the tests.\n", .{}); |
||||
|
||||
try stdout.flush(); // Don't forget to flush! |
||||
} |
||||
|
||||
pub fn add(a: i32, b: i32) i32 { |
||||
return a + b; |
||||
} |
||||
|
||||
test "basic add functionality" { |
||||
try std.testing.expect(add(3, 7) == 10); |
||||
} |
||||
Loading…
Reference in new issue