Package help for SSO string library (and libexec question)

Help
1

I have no idea how to use the build system or zon.

How would I package this for use in other project (I have another that I want to use this and right now I just copy and paste the files into it). I would like to know how to package it for github retrieve, but also how to use it locally without being all tarred up.

eg. I have a base ~/zdev directory with all my independent projects, and I want to be able to treat each dir I think like a module/package (I don’t know the difference) so I can quickly make changes to the lib then go back to the main app and rebuild easily.

(unrelated, how do I make a libexec in zig - runnable library with an entry point like ld.so)

2

From what I’ve understood up til now, in your build.zig.zon, its recommended to list out in the paths field the files and directories that actually make up your package because the ones listed are the ones used to generate the hash that uniquely identifies it. If you’re sure that all the files are always just the ones needed for this, you can leave the empty string "" like you have now, which uses all the files to create the hash.

In you build.zig you can define a module to be imported by users of your lib with addModule, for example:

    _ = b.addModule("zig-string", .{
        .root_source_file = b.path("src/string.zig"),
        .target = target,
        .optimize = optimize,
    });

If all your public API is in that file, then that’s pretty much it. You can then create tag your commit, say v0.1.0 and users of your lib can do a:

zig fetch --save https://github.com/jnordwick/zig-string/archive/v0.1.0.tar.gz

To add the dependency to their build.zig.zon. Then in their build.zig they can add your module to their executable for example:

const zs = b.dependency("zig-string", .{});
//...
exe.root_module.addImport("zig-string", zs.module("zig-string"));

Then in their source file:

const zs = @import("zig-string");

In your local packages, you can add a path dependency in build.zig.zon

dependencies = .{
  .zig-string = .{ .path = "../zig-string" },
},

I haven’t tested it, but I think the dash in zig-string is going to be a problem. If so, I believe zig fetch allows an extra arg after the URL to specify an alternate name for the dependency.

EDIT: Just did a zig fetch and it adds it as @"zig-string to avoid the problem with the dash. So it should all work.

3

So addModule goes in the zig-string build.zig, not the consumers of it? That exports the module?

and what’s the difference between a module and a package?

4

Correct on both. If you have different source files provding public APIs, you could add module for each of them.

A package is a Zig source tree that provides modules for user packages to import and can be added as a dependency. A module is like a unit of Zig code that can provide a public API to be imported via @import or even just data to be embedded via @embed. Here’s the GitHub issue that discusses the terminology: build system terminology update: package, project, module, dependency · Issue #14307 · ziglang/zig · GitHub

Build System Guide

2 Likes
5

off topic, but didn’t want to start a new one: is there a way for force zig to rerun all the tests even if has cached result already?

6

I don’t know if there’s a better way, but trashing the cache directory works.

7

I don’t know if there’s a better way, but trashing the cache directory works

I get freaked out to type rm -rf zig-* that im going to fuck it up and blow away someting important instead. Time to introduce a Makefile into the project because I’m too chicken to actually type that line.

(make clean is actually really useful anyways)

1 Like
8

But what is the point, unless the tests really are undeterministic / have inputs that aren’t properly tracked?

9

I want to make sure they are running, and when in the cache it doesn’t seem to report anything on them (summary all doesn’t even say how may ran once they are all in the cache).

I wish more time was spend on making the test runners more informative than making them look pretty. They good great, just sometimes they aren’t very useful.

10
1 Like