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

reply
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.

reply
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.
reply
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!

reply
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!
reply
Thanks for the link! I’ve never seen this one. I’m going to take a look through it.
reply
Please post it here when it's ready! I'd absolutely be interested in seeing it.
reply
Thanks for the encouragement! It really means a lot. Something should be out around the other side of the new year.
reply
Good luck! Building the next uv is certainly ambitious, but I love ambitious projects :)
reply
In my case, to a fault…
reply
I've used Conan briefly in the past for C++ and I quite liked it.
reply
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.

reply
is it already in open source? I would like to see and test it. Share it here - on HN, when you will be ready
reply
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.
reply
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!
reply
Thanks for the kind words! I really appreciate it.
reply
How is this different from bazel?
reply
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.
reply
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.
reply
bazel is large and complex. aimed at a ton more languages, not just C
reply