Show HN: Seastar – Build and dependency manager for C/C++ with Cargo's features

[AI314159]

Hi hackers!

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.

[no_circuit]

I wouldn't recommend Cargo as something to copy for a real project, even though I've a fan of and have been using Rust exclusively lately. It suffers from not being able to handle global features without manually/conditionally propagating features to dependencies, as well as not being able to propagate metadata to dependencies without abusing the links functionality.

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/

[AI314159]

Thank you for your advice! Yes, this is partially for Hack Club, partially as a personal project. I'll look into Bazel and Buck2.

[AI314159]

Hi again people! I would just like to clarify something if your new to the thread: this is not currently meant to replace actual systems, or to even be something that is used. I didn't really expect this thread to get so popular, or to even take this project seriously. For me, at least, it wasn't a serious project. I might begin turning it into one, and all of you have given me great feedback -- thank you!

However, I, and as you've made it clear, you all as well, think that this project is not ready. It's 0.1.0-alpha.1! I will continue to improve and build upon it, and there are many issues I'll fix. In the meantime, I'll add a thing on the README that says this.

[mryall]

Looks like a great start. Using Rust and TOML configuration are good choices.

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

[AI314159]

Thanks, that's great advice! I'll consider it. I've been meaning to update the readme for a while now, so this just gives me an excuse to do so. I think the most important thing to work on right now is compatibility. Obviously, people like OpenCV or Vulcan aren't going to switch, and so it should at least be easy for those who do to make the switch.

[dmead]

Just a comment on the name. Seestar, C* are already things that exist. You may want to think up something different.

[AI314159]

Thanks! I always have trouble coming up with names (any suggestions would be awesome), so I often end up giving temporary names, and then forget to rename :/

[hedora]

Depending on what you’re targeting, you might prioritize compatibility with debian packages over cmake.

Cmake is a hot mess, but gets you windows compatibility.

Debian would work better with the lion’s share of open source c / c++.

[r2vcap]

I know many people are dissatisfied with existing C++ build systems like CMake, and I understand why. However, before creating a new build system, one must first understand C++’s current position. These days, C++ is chosen less frequently due to the wide range of alternatives available. Still, C++ shines when it comes to bridging distinct components. While it’s tempting to optimize for the simplest use cases and make things as concise as possible, real-world C++ build systems often need to handle a wide variety of tasks—many of which are not even C++-specific. That’s where CMake proves its value: it can do almost anything. If a new build system can’t handle those cases, it’s likely to be dead on arrival.

[AI314159]

An excellent point! I hope I'll be able to handle those cases in the future, and I am kind of seeing this situation: people aren't understanding that this is _the first alpha pre-release of 0.1.0 software._ It isn't going to do everything. It was mostly a test of my skills that started to turn into a serious project, which it wasn't really intended to be.

[mgaunard]

many build systems have a notion of build targets, with various target types (static/shared library, module, executable, etc.).

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?

[AI314159]

Currently, I just have "binary" targets, which output an executable, and "library" targets which output a static library. This is decided by a flag in the TOML [package] table: is_lib = true|false. For a binary project, it just links as normal, using the compiler as the linker by default (also can be changed through TOML). Thus, the entry point is `main()`. However, for libraries, the object files are configured the same, and it calls my link function, but with different arguments and `ar` set as the linker. Therefore, a `.a` file is created. (Probably this is my biggest source of Windows incompatibilities)

[geokon]

Dependency management is a solved problem in the C/C++ world.

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)

[augusto-moura]

Solved problem is a strong statement. I've never heard of Hunter before. And as far as I can remember the most popular way of solving this is having a list of dependencies in a README somewhere so you can install them and their headers with your os/distro package manager

[gavinray]

Not to be confused with Scylla DB's "Seastar" C++ non-blocking event driven server SDK

https://github.com/scylladb/seastar

[AI314159]

I know, others have mentioned it as well. Seastar is a temporary name I forgot to change, and if you have any suggestions, feel free to provide them!

[revskill]

How did people live without this for c projects is beyond my imagination.

[motorest]

> How did people live without this for c projects is beyond my imagination.

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.

[PaulDavisThe1st]

libfftw3 is one the most widely used Fast Fourier Transform open source libraries.

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?

[geokon]

I think this was maybe true a decade ago...

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

[AI314159]

I'm not sure, probably not right now, but I'll try!

[pjmlp]

Anyone is free to use whatever tools they feel like, however me personally I tend to use tools that are part of the ecosystem I am currently using for the task at hand.

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.

[scuol]

Highly recommend you rename because of a name clash with an existing famous C++ framework: https://seastar.io/

[AI314159]

Thank you for the tip! Yeah, I was probably gonna rename either way, funny I didn't find that when Googling...

[throwaway70985]

[flagged]

[AI314159]

It's kind of the-chicken-and-the-egg scenario. I wanted a hospitable development environment to build a hospitable development environment. Also, prebuilt binaries work just fine. I made this in around eleven hours, so it should be fairly easy to rewrite in other languages if that is what the community wants. This project is already getting a lot more attention than I was expecting, and it is definitely still in alpha. However, you can use whatever tools you want to use.

[jdcasale]

As opposed to taking like 30 seconds to install cargo and rust?

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?