It started out as something marginally more useful than vendoring your dependencies as submodules + baking in the knowledge of how to build a bunch of common projects.
I realized, though, that there was somehow a huge gap in the insane world of C build tools. There's nothing that:
- Lets you pin really precisely and builds everything from source (i.e. no binary repository)
- Does not depend on either a scripting language or a completely insane DSL (Conan uses Python, CMake is an eldritch horror, ditto Make, lots of other tools of course but none of them quite hit the mark)
- Has a good balance of "builds are data" and "builds are code".
Anyway, it's going great. There are, of course, a ton of problems to solve. Chief among them is the obvious caveat that C is not a monoculture like Rust. There will be zero upstream libraries that use this tool natively. But I don't think it matters. I think I can build something which is as much better to the existing tools as, say, UV was to existing Python tools, even with that disadvantage.
I love programming in rust. Lots of non-rust developers think the whole point of rust is safety, but honestly, the things I like most about using it are the quality of life features like cargo. I love the idea of bringing that to C!
Relevant to this thread: I've spent the last week or so hand porting SeL4 from C to Rust, mostly so I can learn how it works (and learn OS development more generally). One of the biggest pain points I've had trying to use SeL4 is understanding the insanely complex way it uses cmake to compile the kernel and userland software. With Cargo, I can just run `cargo build` on my rust kernel project and it just works[1]. I don't even have a build.rs.
Anyway, I'd love it if we had a tool that made sel4 so easy to build. I doubt it'll be that simple, but its a lovely goal.
[1] (Well, except for one small step: You need to run objcopy to convert the 64 bit elf into a 32 bit elf to run it in qemu. But other than that!)
I'd love to see it. Though if the package is just "we run sel4's cmake script and save the result" then its much less interesting. If you can make a package which doesn't use cmake at all, email me. My email is in my bio.
Yes, for now the approach is to provide simple programmatic interfaces over CMake and friends to make third party stuff easy to integrate. For example, SQLite:
spn_autoconf_t* ac = spn_autoconf_new(dep);
spn_autoconf_add_flag(ac, "--disable-tcl");
spn_autoconf_run(ac);
spn_make(dep);
But! This is just the bridge. The tool of course has a native build system (i.e. construct and execute a build graph). It's not feasible to start by rewriting every library's build system, so we start like this.
That being said, I'll have a go at sel4 with the native build system. I use it for all my C projects already. Nothing tastes better than dog food, after all!
Sounds interesting and challenging. There's something similar, although not the build part just the modular aspect of it inspired by CPAN called CCAN: https://ccodearchive.net/. Very few people know about it, I believe, and it goes way back. I'm not involved with that project, though. Good luck!
Me too! It's pretty good. Unfortunately, it depend on Python. Not that Python's that bad. It's just that it's completely bonkers to me that building C, the most fundamental language that's commonly written today, the language that every other language has an FFI for and three quarters of them either are written in or were bootstrapped with a version written in -- that this language depends on PYTHON to build!
It's crazy, and I understand why it's the case, but I know how to fix it and I'd like to have a crack at it.
Yup! But not in any state to be linked, really. First impressions are a big deal. If you’re really curious, my GH handle is tspader and the repo is spn. The graph branch has been the main branch for a month or so, I need to merge badly.
Thanks, it looks promising!
I built it and felt cargo-style - friendly and colorful.
Look like you really know what you do and what C community wait from such tool.
So, I leave my humble star on repo :). Good luck!
It started out as something marginally more useful than vendoring your dependencies as submodules + baking in the knowledge of how to build a bunch of common projects.
I realized, though, that there was somehow a huge gap in the insane world of C build tools. There's nothing that:
- Lets you pin really precisely and builds everything from source (i.e. no binary repository)
- Does not depend on either a scripting language or a completely insane DSL (Conan uses Python, CMake is an eldritch horror, ditto Make, lots of other tools of course but none of them quite hit the mark)
- Has a good balance of "builds are data" and "builds are code".
Anyway, it's going great. There are, of course, a ton of problems to solve. Chief among them is the obvious caveat that C is not a monoculture like Rust. There will be zero upstream libraries that use this tool natively. But I don't think it matters. I think I can build something which is as much better to the existing tools as, say, UV was to existing Python tools, even with that disadvantage.