[HN Gopher] Show HN: Seastar - Build and dependency manager for ...
___________________________________________________________________
Show HN: Seastar - Build and dependency manager for C/C++ with
Cargo's features
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.
Author : AI314159
Score : 27 points
Date : 2025-06-15 19:36 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dmead wrote:
| Just a comment on the name. Seestar, C* are already things that
| exist. You may want to think up something different.
| AI314159 wrote:
| 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 :/
| scuol wrote:
| Highly recommend you rename because of a name clash with an
| existing famous C++ framework: https://seastar.io/
| AI314159 wrote:
| Thank you for the tip! Yeah, I was probably gonna rename either
| way, funny I didn't find that when Googling...
| teitoklien wrote:
| kinda surprising lol, seastar runs all sorts of popular stuff
| like ScyllaDB (a nosql performant db meant to be a
| replacement to Cassandra)
| revskill wrote:
| How did people live without this for c projects is beyond my
| imagination.
| motorest wrote:
| > 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.
| AI314159 wrote:
| This, also my goal wasn't necessarily to replace existing
| tools, but to fill a gap. "If it isn't configured in TOML it
| isn't worth using" is something that I've heard, whether or
| not you agree. As for system packages, version conflicts do
| happen. My goal wasn't to replace existing build systems, or
| replace existing package managers, but to combine them. It
| isn't very good in its current state, but by combining two
| essential tools into one, I hopefully make it easier.
| mryall wrote:
| 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 wrote:
| 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.
| gavinray wrote:
| Not to be confused with Scylla DB's "Seastar" C++ non-blocking
| event driven server SDK
|
| https://github.com/scylladb/seastar
| AI314159 wrote:
| 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!
| hedora wrote:
| 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++.
| throwaway70985 wrote:
| > Seastar is very simple to build and run. Assuming you have
| Cargo and Rust installed
|
| Guess I'll just stick with CMake.
| AI314159 wrote:
| 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.
| maccard wrote:
| A good goal for these sorts of projects is bootstrapping -
| can you build seastar with seastar?
| AI314159 wrote:
| Since Seastar is written in Rust, and I don't have Rust
| support yet...no. However, it should be fairly simple to
| add. Despite what people want me to do, I am not going to
| fully reimplement Cargo -- it took the Rust devs years, and
| I'm just one person. However, I can call Cargo with the
| correct flags and config files to interface with my
| existing code, and I am planning on doing that soon.
| mgaunard wrote:
| 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 wrote:
| 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)
| mgaunard wrote:
| 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.
| AI314159 wrote:
| That's alright! However, if you don't mind me asking, what
| would make you potentially interested?
| r2vcap wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-15 23:00 UTC)