New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Add snapcraft.yaml #1056
WIP: Add snapcraft.yaml #1056
Conversation
Thanks for the PR. A couple questions - We have automatic builds of a completely statically linked zig for linux on every master branch push. These come out to about 25MB and work on every Linux distro. What does Snapcraft provide over this? Does Snapcraft work for linux distros that do not follow the LFS such as NixOS? Does it makes sense for this to be in a separate git repository? |
If you have a working zig compiler then you can run these tests:
I would recommend not including the tests in the package, however. For example one of the compiler-rt tests is 10MB.
These are part of the build process for building stage 2 and stage 3, but not intended to be distributed to zig users. (Also note that currently it is recommended to only distribute stage 1. See README.md for more details.) |
The snap is currently 27MB. This should go down a bit once I remove the stage 2 and 3 stuff.
If hooked up to build.snapcraft.io, it will provide:
It's basically the same reasons why you might provide Homebrew or
I'm not sure.
Cool, these tests pass with the toolchain packaged in the snap. I just wanted a way to double-check. I don't plan to package them. |
This all sounds like good stuff to me. Thanks again |
So it looks like what we would want to do is in the ci/linux_script, after all tests pass, after uploading the static tarball, do the build and push process for snapcraft. |
I rebased off latest master and pushed a new commit that includes only the stage 1 stuff in the package. I've started playing with build.snapcraft.io on my fork with its webhook. I'll let you know how it goes. |
Oh, and somewhat of a tangent, but the |
What you're observing here is a conflict between us wanting to use stage 1 only to build stage 2, but shipping stage 1 for now since stage 2/3 are not ready yet. In fact the default install directory for stage 1 is equal to the build directory, so it's intended that you "install" stage 1 before proceeding with stage 2, which needs to link against Once stage 2 and 3 are complete I'll revisit the build process and make sure it all makes sense. |
Is this still work in progress, or do you consider it ready to be merged? |
My preliminary test with build.snapcraft.io did not work, but I haven't had time to dig into it more. I think I read somewhere that they don't auto-build snaps with a classic confinement, but need to confirm. |
Alright so snapcraft sounds great, and I think it should go in a separate repo and be maintained by someone other than me. Feel free to request a git push hook if you want to get master branch push notifications. |
Okay, sounds fine. Is there an existing repo for peripheral artifacts? |
There are some here: https://github.com/ziglang I recommend doing a repo under your name as a proof of concept as a first step. |
Configuration moved to https://github.com/jayschwa/zig-snapcraft |
Conclusion: Additions moved to https://github.com/jayschwa/zig-snapcraft.
This is a work-in-progress that packages the Zig toolchain for Ubuntu's new-ish package manager.
After setting up Snapcraft, this can be tested with:
Snaps are just SquashFS files, so it can be inspected with
unsquashfs -ls zig_git_amd64.snap
.