-
Notifications
You must be signed in to change notification settings - Fork 1
vspefs/someday-dev
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
someday: a C/C++ package managing extension for Zig Build System still in early development. proof-of-concept stage. ---- 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. ----
About
A C/C++ package managing extension for Zig Build System. Proof-of-concept stage.
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published