I'm working on "Cargo but for C".

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.

▲ josephg a day ago | parent | next [-]

Nice stuff! I'm keen to see this too.

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!)

▲ dboon 14 hours ago | parent [-]

I’ll have a go at writing a package for sel4 as a delicious bowl of dog food.

Are you interested in the result? If so, just reply with some handle where I can reach you.

▲ josephg 8 hours ago | parent [-]

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.

	▲	dboon 5 hours ago \| parent [-]
		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!

▲ throwaway29303 a day ago | parent | prev | next [-]

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!

	▲	dboon 14 hours ago \| parent [-]
		Thanks for the link! I’ve never seen this one. I’m going to take a look through it.

▲ MarsIronPI a day ago | parent | prev | next [-]

Please post it here when it's ready! I'd absolutely be interested in seeing it.

	▲	dboon 14 hours ago \| parent [-]
		Thanks for the encouragement! It really means a lot. Something should be out around the other side of the new year.

▲ colonCapitalDee 2 days ago | parent | prev | next [-]

Good luck! Building the next uv is certainly ambitious, but I love ambitious projects :)

	▲	dboon 14 hours ago \| parent [-]
		In my case, to a fault…

▲ haolez 2 days ago | parent | prev | next [-]

I've used Conan briefly in the past for C++ and I quite liked it.

	▲	dboon a day ago \| parent [-]
		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.

▲ feelamee a day ago | parent | prev | next [-]

is it already in open source? I would like to see and test it. Share it here - on HN, when you will be ready

▲

dboon 14 hours ago | parent [-]

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.

	▲	feelamee 11 hours ago \| parent [-]
		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!

▲ adastra22 a day ago | parent | prev [-]

How is this different from bazel?

▲

dboon 14 hours ago | parent | next [-]

It’s about as related to Bazel as it is to, say, Maven. Bazel builds huge monorepos which use lots of languages. Not particularly related to C.

	▲	adastra22 13 hours ago \| parent [-]
		Bazel is used by many in the C/C++ world to build projects with dependencies fetched and built from source. It is not monorepo specific.

▲

hu3 a day ago | parent | prev [-]

bazel is large and complex. aimed at a ton more languages, not just C