The library jumped to Zig v0.15.2 which implies a new build system. `build.zig` now compiles libipc as both static and dynamic libraries, and provides an entry point to use `libipc` as-is for Zig applications. Some examples have been added to help new users play with the library. Thanks to these fairly complete examples, two (very small) leaks related to sentinel values (in arrays containing paths) were fixed.
208 lines
9.5 KiB
Zig
208 lines
9.5 KiB
Zig
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("ipc", .{
|
|
// 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/zigroot.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,
|
|
.optimize = optimize,
|
|
// libc is required since libipc uses umask.
|
|
.link_libc = true,
|
|
});
|
|
|
|
// Compile libipc as a static library with C bindings.
|
|
const static_lib = b.addLibrary(.{
|
|
.name = "ipc", // name of the library
|
|
.linkage = .static,
|
|
.root_module = b.createModule(.{
|
|
.root_source_file = b.path("src/root.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
.link_libc = true, // libc is required since libipc uses umask.
|
|
}),
|
|
});
|
|
b.installArtifact(static_lib);
|
|
|
|
// Compile libipc as a dynamic library with C bindings.
|
|
const dynamic_lib = b.addLibrary(.{
|
|
.name = "ipc", // name of the library
|
|
.linkage = .dynamic,
|
|
.version = .{ .major = 0, .minor = 2, .patch = 3 },
|
|
.root_module = b.createModule(.{
|
|
.root_source_file = b.path("src/root.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
.link_libc = true, // libc is required since libipc uses umask.
|
|
}),
|
|
});
|
|
b.installArtifact(dynamic_lib);
|
|
|
|
// pong client using the c client.
|
|
const pong_with_c_bindings = b.addExecutable(.{
|
|
.name = "pong-with-c-bindings", // name of the executable
|
|
.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("examples/pong-with-c-bindings.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
|
|
// There is no list of modules to import since the application
|
|
// uses `libipc.h` to type-check the API then it is statically
|
|
// linked to libipc (see `linkLibrary(static_lib)`).
|
|
}),
|
|
});
|
|
|
|
// 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(pong_with_c_bindings);
|
|
|
|
// Statically link the executable to the library.
|
|
pong_with_c_bindings.linkLibrary(static_lib);
|
|
|
|
// pong service using the c client.
|
|
const pongd_with_c_bindings = b.addExecutable(.{
|
|
.name = "pongd-with-c-bindings", // name of the executable
|
|
.root_module = b.createModule(.{
|
|
.root_source_file = b.path("examples/pongd-with-c-bindings.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
|
|
// Again, no need for external modules to import.
|
|
}),
|
|
});
|
|
b.installArtifact(pongd_with_c_bindings);
|
|
pongd_with_c_bindings.linkLibrary(static_lib);
|
|
|
|
// pong client using the zig library directly.
|
|
const pong = b.addExecutable(.{
|
|
.name = "pong", // name of the executable
|
|
.root_module = b.createModule(.{
|
|
.root_source_file = b.path("examples/pong.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
|
|
.imports = &.{
|
|
.{ .name = "ipc", .module = mod },
|
|
},
|
|
}),
|
|
});
|
|
b.installArtifact(pong);
|
|
|
|
// pong service using the zig library directly.
|
|
const pongd = b.addExecutable(.{
|
|
.name = "pongd", // name of the executable
|
|
.root_module = b.createModule(.{
|
|
.root_source_file = b.path("examples/pongd.zig"),
|
|
.target = target,
|
|
.optimize = optimize,
|
|
|
|
.imports = &.{
|
|
.{ .name = "ipc", .module = mod },
|
|
},
|
|
}),
|
|
});
|
|
b.installArtifact(pongd);
|
|
|
|
// 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_pong_with_c_bindings_step = b.step("run-pong", "Run the pong client");
|
|
|
|
// 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_pong_with_c_bindings_cmd = b.addRunArtifact(pong_with_c_bindings);
|
|
run_pong_with_c_bindings_step.dependOn(&run_pong_with_c_bindings_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_pong_with_c_bindings_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_pong_with_c_bindings_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 = pong_with_c_bindings.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.
|
|
}
|