Github.com/allyourcodebase

All Your Codebase is a GitHub organization that I’ve created to collect build.zig files of C/C++ projects both to make it easier for Zig community members to depend on C libraries, and also to have a showcase of what using Zig to build C/C++ projects looks like.

…and also so that people don’t go pestering C/C++ maintainers about adding a build.zig file if they don’t want to.

You can read more on by reading the org’s description on GitHub.

If anybody here is interested in contributing to it, the price of admission is one packaged C/C++ project that you want to transfer to the organization. Just ping me in this thread, via a DM, a discord message or an email, whichever works best for you.

If you’re happy with owning your own code, you should do so of course, but transferring the repo to an organization has the upside that other people might take on some of the maintainer work in your stead, which should be a welcome thing considering that most of the time packaging a C/C++ library is done for purely utilitarian reasons.

39 Likes

I have several C and C++ projects designed just for zig build.
Especially C++ with boost-libraries using zig-pkg without machine installation.

If you’re interested in related projects that might benefit the community, don’t hesitate.

Hi Matheus, I’ve added you to the AYC organization, feel free to move any repo you think would make sense to gift to AYC.

I looked at some of your repos, the only request I have is to make sure to read first the AYC readme (it’s the main thing you see when opening the organization homepage) as that contains a list of requirements for a repo to be added to AYC.

In particular, I would ask you to use the “pristine tarball” strategy whenever possible. That’s where you don’t fork the original repo and instead depend on it in your build.zig.zon file. You can see some examples of those already present in AYC.

3 Likes

I’ve also found the “pristine tarball strategy” to work nicely. Do you have any insights or thoughts to share on how you landed on it?

Does creating a submodule to the source and depending on it by specifying the path also be “pristine tarball” strategy?

Totally saw somebody else (probably Andrew) do it and thought it was neat.

I remember that in the beginning it just wasn’t possible because the build system didn’t have the necessary APIs, then at some point all the missing pieces were added and a few of projects structured this way popped up here and there.

If we want to be technical a submodule is not a tarball, but it would maintain the same spirit of making a clear distinction between the original project and your additions to it.

That said, for AYC I would avoid them unless the original project is already making use of them (which probably means that you can’t depend on the project as a literal autogenerated tarball).

2 Likes

@kristoff Please add me to this org, I already made jemalloc zigged with zig build, no autoconf is required.

In future, I plan to package rocksdb.

1 Like

This is a good project! Just as a suggestion, the description would be better phrased as “Zig allocator using jemalloc” or “Zig allocator backed by jemalloc”.

I would expect “Zig allocator based on jemalloc” to be Zig code which is, or at least started as, a port of jemalloc to pure Zig. Indeed there is at least one such allocator in existence.

1 Like

Thanks for pointing out, updated.

1 Like