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

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

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

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

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

https://github.com/scylladb/seastar

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

[flagged]

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?

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.

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?

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)

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/

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.

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.