Show HN: Seastar – Build and dependency manager for C/C++ with Cargo's features
I'm a self-taught solo teenage dev working on Seastar, a unified build system and dependency manager for C and C++. It is capable of compiling and linking projects, managing recursive dependencies and headers, and even has a template system -- your C++ library is one `seastar new mylib --lang c++ --lib` away! Also, everything is configured in TOML, because TOML is awesome.
C is one of my favorite languages, but I usually end up writing stuff in Rust because I love Cargo. Unlike C, Cargo handles the dependencies, linking, globbing, and so much more for you. So I wrote Seastar to give that function in C and C++.
What's planned? A package registry like crates.io, compatibility with CMake projects, commands to migrate, and so much more. If you have more ideas, please give them!
I am trying to reach 150 stars by the end of summer, and thus a star would be greatly appreciated! This project is still in development, and a star helps out a ton.
Why is that important? Well that's useful if you want something like json/serde or not in all transitive dependencies for a particular artifact you are generating like a library or a binary. That applies for other configurability that C/C++ developers bake into their libraries too.
Is this an educational learning experience as part of Hackclub which is a linked organization on your GitHub profile? Whether or not if so, trying to build this will be a good learning experience.
Think beyond just C/C++ and maybe Rust...
The entire set of ideas of things to implement is just to look at the feature set of Bazel and Buck 2 (which happens to also be written in Rust). Those offer functionality to build complete products in any language, locally or distributed across a build farm of servers, and glue them all together in any format. For example you can't build a multi-arch OCI/Docker container image for a Rust-binary server in a single command with Cargo.
Except for the initial learning curve, using them could be as simple as including their "build" files in your published git repo. No central repository needed.
https://github.com/hackclub https://bazel.build/about/why https://buck2.build/docs/about/why/
With a project like this where there are many (many) existing attempts to solve it, I think it helps to take a hard look at what exists today and design your solution to solve a specific problem you see.
Then you can pitch it that way to your first adopters too - something like “Basel, but with easier deps” or “CMake, but with config humans can understand”.
Cmake is a hot mess, but gets you windows compatibility.
Debian would work better with the lion’s share of open source c / c++.
It all should be done from within CMake using Hunter. They handle diamond dependencies correctly (everyone else just yolos it), they handle "package registry" correctly, ie git repos + hash verification. They handle tool chain files and forwarding of compilation flags correctly. I had a library building for like a dozen targets with it (including crazy stuff like iOS 9)
You don't have that (which I personally find is good, but that's arguably because I'm opinionated about not having libraries), but how do you deduce what to link and what are the entrypoints?
so no interest from me personally.
Is the alternative just one library or executable, with namespaces and directory structure being the source of truth for organization of a codebase?
https://github.com/scylladb/seastar
They didn't. Things like Conan and vcpkg exist for almost a decade by now.
Also, on any OS under the sun except Windows, the system's package manager is C's and C++'s package manager. These C package managers called deb or rpm are older than half the people posting here.
Hence why I am on the vcpkg side, and not conan, as the former is written in C++.
Trying to offer a build tool to C and C++ developers written on the language they are currently having issues like talking about Valdermort, isn't properly the quickest way for adoption.
It can be built to be used in a single-threaded environment, or a multi-threaded one. It can be built to use 32 bit or 64 bit floating point as its internal data type.
Any build system that cannot handle or allow me to express "I depend on the single-threaded 64 bit version of libfftw3" doesn't get my attention.
Does yours?
Having to contact them to get a license is a pain, and in benchmarks there are on-par or better libraries available. The tuning steps are baroque and if you really care about performance that much.. You'd probably look at GPU solutions
Are you expecting to do the tuning step during the build?
Last I checked their arm support was terrible.. But maybe that's changed
Any build system that won't allow us to do this is unusable.
I get that the elegant thing to do would be to bootstrap this, but in practice does this actually cost you anything, or is this a purely aesthetic concern?
I think you're oblivious to the problem domain. C and C++ projects are tightly coupled with build systems. If you are not smack middle in the happy path, you will experience problems. Having to onboard an external language and obscure toolset just to be able to start a hello world is somewhere between a hard sell and an automatic rejection.