From 815331f323028b4ca75436eca337902c31cb5860 Mon Sep 17 00:00:00 2001 From: Tim Wundenberg Date: Sun, 7 Dec 2025 14:39:02 +0100 Subject: [PATCH] setup --- .gitignore | 3 ++ build.zig | 119 -------------------------------------------------- build.zig.zon | 71 ++---------------------------- src/main.zig | 3 -- src/root.zig | 23 ---------- 5 files changed, 6 insertions(+), 213 deletions(-) create mode 100644 .gitignore delete mode 100644 src/root.zig diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..58204f5 --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ + +zig-out/ +.zig-cache/ diff --git a/build.zig b/build.zig index 2f32de0..24fe981 100644 --- a/build.zig +++ b/build.zig @@ -1,156 +1,37 @@ 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("websockets", .{ - // 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 = "websockets", .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 "websockets" is the name you will use in your source code to - // import this module (e.g. `@import("websockets")`). 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 = "websockets", .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. } diff --git a/build.zig.zon b/build.zig.zon index 4658891..7313c97 100644 --- a/build.zig.zon +++ b/build.zig.zon @@ -1,75 +1,10 @@ .{ - // This is the default name used by packages depending on this one. For - // example, when a user runs `zig fetch --save `, 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 = .websockets, - // 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 = 0xa9f10aa30d7b02d1, // Changing this has security and trust implications. - // Tracks the earliest Zig version that the package considers to be a - // supported use case. + + .fingerprint = 0xa9f10aa30d7b02d1, .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 ` 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", diff --git a/src/main.zig b/src/main.zig index 0ed5517..545c30f 100644 --- a/src/main.zig +++ b/src/main.zig @@ -1,10 +1,7 @@ const std = @import("std"); -const websockets = @import("websockets"); pub fn main() !void { - // Prints to stderr, ignoring potential errors. std.debug.print("All your {s} are belong to us.\n", .{"codebase"}); - try websockets.bufferedPrint(); } test "simple test" { diff --git a/src/root.zig b/src/root.zig deleted file mode 100644 index 94c7cd0..0000000 --- a/src/root.zig +++ /dev/null @@ -1,23 +0,0 @@ -//! 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); -}