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

Show HN: Seastar – Build and dependency manager for C/C++ with Cargo's features github.com/AI314159/Seast...

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.

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 · 7 months ago

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

no_circuit · 7 months ago

AI314159 · 6 months ago

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 · 7 months ago

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

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 · 7 months ago

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

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 :/

smallhands · 7 months ago

Seamonster?

hedora · 7 months ago

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 · 7 months ago

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.

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 · 7 months ago

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?

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)

so a project is a single target, and you still have the notion of libraries (which to me are an anti-pattern).

so no interest from me personally.

geokon · 7 months ago

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 · 7 months ago

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

That's not a serious solution. You don't control dependency versions if you use a package manager and you can't build full static builds or full debug builds etc. Some targets don't have package managers (ex an embedded device)