Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/vspefs/someday-dev

A C/C++ package managing extension for Zig Build System. Proof-of-concept stage.
https://github.com/vspefs/someday-dev

Last synced: about 2 months ago
JSON representation

A C/C++ package managing extension for Zig Build System. Proof-of-concept stage.

Awesome Lists containing this project

README 

        
someday: a C/C++ package managing extension for Zig Build System



still in early development. proof-of-concept stage.



----

current progress, 2025/1/22

to have something fancy buy not really so useful that is the ability to bootstrap a whole C/C++ development environment with only Zig toolchain, I spent some time bootstrapping CMake and Ninja with Zig. and it worked.



then after quite a long while, until now, I finally integrated them into someday, and refactored the project itself a little. looks pretty good.



the base is pretty solid and now it's building up the blocks. I genuinely hope we can have a 1.0 release this month.



----

current progress, 2024/12/26

alright. someday is working. properly.



my dream of "making Zig the one-stop solution to C/C++" is coming true. someday is now building CMake, Ninja, and CMake packages using only Zig toolchain and a standard GNU/Linux environment just right.



the next step is to make it more user-friendly and add basic features. better logging, better error messages, user custom args, etc. we also have a generic package consuming support, which makes adding support for other build systems/package management systems really easy.



let's say we should have a 1.0 release with a wide range of support before 2025.



----

current progress, 2024/12/17

happy christmas or just another day, depending on your culture!



been working on the whole dependency and profile stuff for a while, but only until now am I able to deliver a working commit. real life issues plus my noob skill issues, sorry.



Usage of Zig's dependency is pretty much working, while profile and more package customization is still in progress. the way to add a package to a Zig `std.Build.Step.Compile` or to use it for other purposes needs optimization, too. Internal logic could use some refinement. Still need to figure out (if we can) how to make Zig C/C++ linker work properly and independently.



but it's functional! and code quality leaps from 'bad' to 'just-so-so'.



oh, besides, I found myself suck at using git. I'm not sorry because it's, as you can see, a draft repo. I'll learn how to git someday. (it's not a pun because if it is it's a bad pun)



----

current progress, 2024/12/02



it was silly of me. after checking out Zig compiler's source, I finally found out that in your 'build.zig', you can just `@import()` your dependency's 'build.zig' file.



this makes things extremely simple. so this time we're having our first working version of someday here. check out the 'example' folder for more information.



however, for now, this is just a "try it out" version. I think we still have a few things to do before a serious release.



1. clean up the shitty memory management.



2. custom build args for packages.



3. avoid rebuilding packages. in a better way, i mean.



4. optimize the whole process. better logging, etc. (to be exact, refactor my rather draft-y code)



4. a few more build system support, maybe?



I just added them to 'TODO'. also, we'll have to settle this question:



5. now when the content of 'build.zig' changes, even if everything about the package is the same, the package will still be rebuilt. it's not necessarily bad, and as a matter of fact, it seems to be a proper Zig Build System feature.

   however, it does make things like global cache of packages more complex and difficult. it might seem nothing when we're cloning a package from a git repo, but if we're to download packages from a package management server, it might cause problems.

   what to do?



----

current progress, 2024/11/29



1. someday can already be consumed correctly by zig build system in 'build.zig.zon' files.



2. use `@import("someday")` to get access to someday exported module.

   this is currently impossible to do in a 'build.zig'. all we can do now is to test building CMake/Ninja and invoking them in a raw way, in a Zig Build System project's source file.



3. tools including CMake, Ninja, and Zig toolchain for C/C++ are placed in the same folder where the someday package source is.

   --- some_folder --- build.zig (of someday)

                    |- build.zig.zon

                    |

                    |- src - ...

                    |- deps - ...

                    |

                    |- tools - where those tools would be placed



4. `someday.getConfig()`

   it returns specific configurations for each project. it is necessary, as it contains all paths someday needs, some of which are relative to the project's root folder (used for project-specific C/C++ package building cache, etc).

   or maybe it's not needed. we'll see.

   `someday.setupZigTools()`

   it sets up Zig toolchain for C/C++ in someday's global 'tools' folder, and returns a `std.process.EnvMap` containing all environment variables needed for someday internal invocations to work.

   it's safe to be called multiple times, at any place.

   internal function. exposed for testing.

   `someday.buildCMake()`

   builds CMake. build cache and installed binaries are placed in someday's global 'tools' folder.

   it's safe to be called multiple times, at any place.

   `someday.buildNinja()`

   builds Ninja. build cache and installed binaries are placed in someday's global 'tools' folder.

   it's safe to be called multiple times, at any place.



   I'll leave a example that tells someday to build CMake and Ninja here:



```zig

const std = @import("std");

const someday = @import("someday");



pub fn main() !void {

    var arena = std.heap.ArenaAllocator.init(std.heap.page_allocator);

    defer arena.deinit();

    const allocator = arena.allocator();



    const config = try someday.getConfig(allocator);

    try someday.setupZigTools(allocator, config);

    try someday.buildCMake(allocator, config);

    try someday.buildNinja(allocator, config);

}

```



5. the memory management is shit. because I simply don't want to do it. 

   just use `std.heap.ArenaAllocator` for everything and `deinit()` it in the end. will fix it later.



6. I hardcoded things like "--parallel=12", again because I'm being lazy. will fix it later.



----