Zig: [question/suggestion] Workflow when working on std lib

[squeek502]

Not sure if this is documented anywhere, but it would be a big help if it were, as I'm unsure of what the intended way to make changes to the std library and test them actually is.

On Linux I was making changes to the files in zig/std and then doing make install after every change before running e.g. bin/zig test lib/zig/std/heap.zig from my zig/build directory.

On Windows I'm building a release mode zig compiler, adding zig/build-release/bin to PATH and then doing e.g. zig test std/heap.zig --override-std-dir std from the checked out zig directory.

Curious what core contributors are doing.

[shritesh]

I asked @andrewrk this question during one of his streams and he showed us his workflow and I have adapted mine to be similar to what he described.

I create a build directory in the repository root (this is in .gitignore by default) and work from there.

If I'm working in userland (not the compiler), I create a Release build of the compiler using cmake .. -DCMAKE_PREFIX_PATH=/usr/local/Cellar/llvm/8.0.0 -DCMAKE_BUILD_TYPE=Release from the build directory, (I am on a Mac using Homebrew, so I specify the LLVM path that way. YMMV), and do a make -j$(nproc) install. Then I use the ./zig binary and specify --override-std-dir ../std to every zig command (test, build*, etc) that I run.

Before submitting a pull request, I do a make -j$(nproc) install again, and run the tests with ./zig build --build-file ../build.zig test -Dskip-release. The -Dskip-release skips the test matrix of building and testing on every possible platform and only does so for the host platform. This is what is expected out of contributors.

When working on the compiler itself, I skip the -DCMAKE_BUILD_TYPE=Release so that I can get better stack traces for a tiny-bit slower compilation (maybe this is no longer needed with the hybrid stage 1) .

Hope this helps. I too think this should be documented somewhere.

[andrewrk]

My process

I follow the readme instructions.

POSIX

I definitely recommend the default of debug builds of Zig + release build of LLVM. Debug builds of LLVM are useful sometimes, but not usually.

My CWD is the build directory. After every std lib edit, make install and then test with bin/zig. (same as @squeek502)

Windows

Unfortunately I was unable to make it work with a release build of LLVM + debug build of Zig. So I actually test with zig in release mode.

Again my CWD is the build directory. After every std lib edit, msbuild -p:Configuration=Release INSTALL.vcxproj, and then test with bin/zig.exe.

Hope this helps. I too think this should be documented somewhere.

All the above information matches the readme + wiki pages linked to by the readme. I'm open to suggestions for clarification.

[squeek502]

Thanks! @andrewrk is there a benefit to running make install (or equivalent) after every change vs. using --override-std-dir?

All the above information matches the readme + wiki pages linked to by the readme. I'm open to suggestions for clarification.

I'm missing where this is. Could you link to it?

[andrewrk]

The make install route is how users will use Zig. The more closely the way developers use it to the way users use it, the more well tested the user's experience will be. The reason --override-std-dir exists is for the startup code to be properly tested when running the std lib tests, and so that we don't have to ship large *_test.zig files.

I'm missing where this is. Could you link to it?

Yep: https://github.com/ziglang/zig#instructions

[squeek502]

Alright, thanks for the answers.

Yep: https://github.com/ziglang/zig#instructions

That doesn't mention the type of stuff answered in this issue: how to test changes to userland while making changes to it. I'll try drafting up a PR to add that info to the readme.