Highly recommend you rename because of a name clash with an existing famous C++ framework: https://seastar.io/
AI314159 7 hours ago [-]
Thank you for the tip! Yeah, I was probably gonna rename either way, funny I didn't find that when Googling...
teitoklien 6 hours ago [-]
kinda surprising lol, seastar runs all sorts of popular stuff like ScyllaDB (a nosql performant db meant to be a replacement to Cassandra)
no_circuit 2 hours ago [-]
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.
Thank you for your advice! Yes, this is partially for Hack Club, partially as a personal project. I'll look into Bazel and Buck2.
r2vcap 5 hours 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.
AI314159 5 hours ago [-]
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.
throwaway70985 6 hours ago [-]
> Seastar is very simple to build and run. Assuming you have Cargo and Rust installed
Guess I'll just stick with CMake.
AI314159 6 hours ago [-]
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 5 hours ago [-]
A good goal for these sorts of projects is bootstrapping - can you build seastar with seastar?
AI314159 5 hours ago [-]
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.
ronsor 28 minutes ago [-]
Arguably a package manager shouldn't be so complex that it takes many developers years to implement.
geokon 2 hours 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 2 hours 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
geokon 2 hours ago [-]
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)
augusto-moura 2 hours ago [-]
It is not, but it is the standard. So I would this is _not_ a solved problem
mryall 7 hours 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”.
AI314159 7 hours ago [-]
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.
PaulDavisThe1st 4 hours ago [-]
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 2 hours ago [-]
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
PaulDavisThe1st 2 hours ago [-]
Also, why do you "have to contact them to get a license" ? It's intentionally an open source library, release under the GPL. If you want to use it in a closed source context, sure, you'd probably look elsewhere.
PaulDavisThe1st 2 hours ago [-]
What I'm expecting: we have our own ad-hoc "build system" which is a shell script that configures, builds and installs all our dependencies (about 80 libs). That includes tuning the configure step of several different libraries.
Any build system that won't allow us to do this is unusable.
hedora 6 hours 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++.
mgaunard 6 hours 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?
AI314159 5 hours ago [-]
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 5 hours ago [-]
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.
arjonagelhout 3 hours ago [-]
Could you elaborate on why you think libraries are an anti-pattern?
Is the alternative just one library or executable, with namespaces and directory structure being the source of truth for organization of a codebase?
AI314159 5 hours ago [-]
That's alright! However, if you don't mind me asking, what would make you potentially interested?
gavinray 6 hours ago [-]
Not to be confused with Scylla DB's "Seastar" C++ non-blocking event driven server SDK
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!
dmead 7 hours ago [-]
Just a comment on the name. Seestar, C* are already things that exist. You may want to think up something different.
AI314159 7 hours ago [-]
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 :/
How did people live without this for c projects is beyond my imagination.
motorest 7 hours ago [-]
> 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 7 hours ago [-]
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.
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/
Guess I'll just stick with CMake.
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)
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”.
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.
Cmake is a hot mess, but gets you windows compatibility.
Debian would work better with the lion’s share of open source c / c++.
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.