Hey everyone,
I’ve spent the last year building Zyn — a zero-boilerplate build system for C/C++ projects.
It started with a simple frustration: why do I need 50 lines of CMake or Conan config just to use a GitHub library?
With Zyn you just need to put a reference to the library in config.zyn in the [dependencies] section
and boom — Zyn clones the repo, builds it, and links it to your project. No CMakeLists.txt, no conanfile.py, no manual target_include_directories, nothing.
Key Features
Automatic project init (zyn init debug)
Works out of the box — no toolchain hell
Future plans: IDE project generation, CI/CD integration, Windows/macOS support
Why Zyn?
Because build systems shouldn’t get in your way. You shouldn’t need to become a CMake black belt just to compile your code.
Zyn is made for people who want to start fast, stay clean, and ship.
I’d love your feedback. Especially from those who’ve worked with CMake, Meson, Bazel, or Conan in real projects.
Tell me what sucks, what’s missing, or if the core idea makes sense at all.
I‘m curious: How does Zyn integrate with non-Zyn-style projects? I.e. I have CMake/whatever project X that just tries to find dependencies and lists them in some readme to be manually installed by the user (I think that applies to most C/C++ projects out there).
And now, I am listing X as a dependency in Zyn. How does it deal with this situation?
zyntraxis · 24d ago
Zyn can integrate with non-Zyn-style projects (like CMake or Make-based ones), but it treats them as opaque third-party dependencies and handles them externally. Here's how it works:
Cloning: When you list a Git-based dependency like https://github.com/user/X in your zyn.toml, Zyn clones it into .zyn/deps.
Build Detection: Zyn looks for known build systems (CMakeLists.txt, Makefile, etc.) in the dependency. If found, Zyn runs the appropriate commands (cmake, make, etc.) to build the project.
Dependency Isolation: Zyn does not parse or resolve the internal dependency graph of project X. If X needs other libraries (Y, Z, etc.), you must also list those manually in your own zyn.toml. This gives you full control and reproducibility.
Header and Library Exposure: After building, Zyn makes the compiled .a/.so/.lib and headers available to your main project automatically by linking them via -I and -L flags.
Example:
Let’s say project X depends on Y and Z, but doesn’t use Zyn itself and just mentions this in a README. You’d do:
[dependencies]
X = "https://github.com/user/X"
Y = "https://github.com/user/Y"
Z = "https://github.com/user/Z"
Zyn will fetch and build all of them. It doesn’t care that X has no zyn.toml.
90s_dev · 31d ago
> It started with a simple frustration: why do I need 50 lines of CMake or Conan config just to use a GitHub library?
And what answer did you reach? When is it legitimately appropriate? What do we lose out on by using your utility that these older tools do take care of?
zyntraxis · 30d ago
Great question — and I really appreciate the thoughtful framing.
Yes, Zyn started from the simple frustration of needing 50+ lines of boilerplate just to try a GitHub library. My answer was: for most projects, that level of complexity isn't necessary. So I built a tool that does the common 80% use case in 1% of the effort. One line of config, and you're ready to go.
When is CMake or Conan legitimately appropriate?
Absolutely — when you're working with complex multi-platform targets, ABI constraints, custom toolchains, or need deep CI/CD and IDE integration. Those tools are mature and powerful for a reason.
What do you lose by using Zyn today?
Mainly fine-grained control: custom build steps, cross-compilation, binary caching, platform-specific configs — Zyn doesn't try to solve all that (yet). It's intentionally minimal.
But here's the key part:
We do plan to grow in that direction. Future versions of Zyn will support IDE project generation, CI/CD workflows, cross-compilation setups, and even plugin extensibility. The goal is to keep the simplicity, while expanding capability.
For now, Zyn is a productivity-first tool — and I think there's room for that in the C/C++ ecosystem.
gjvc · 31d ago
"we"? do you have any idea how pompous you sound?
90s_dev · 31d ago
We meaning potential users of this build system... I genuinely have no idea what you're on about. I'm just asking for a pros/cons table, pretty standard for a project like this and no knock against it.
> It started with a simple frustration: why do I need 50 lines of CMake or Conan config just to use a GitHub library?
I'm on my phone, and doing this entirely from memory, so I might get some details wrong (although its not too far off), but heres a minimal example of using a lib with Conan+CMake:
conanfile.txt:
[requires]
somelib/1.0.0
[generators]
CMakeDeps
CMakeLists.txt:
find_package(somelib)
...
target_link_libraries(target somelib)
Done. That's 6 lines of code, not 50. Sure, you can't use the full power of Conan with the simpler conanfile.txt, but it's a tradeoff that's fine for most simple cases.
So my question is: if we're comparing Conan's simple mode with your build system, what does yours do better?
(I definitely don't consider myself a CMake black belt)
zyntraxis · 30d ago
You're absolutely right — Conan with a conanfile.txt and minimal CMake can be very concise. And for people already familiar with CMake/Conan, that setup works well.
But here's the key difference:
> In your CMakeLists.txt, when you write find_package(somelib), that only works if the library is already installed and registered properly in the CMake package registry or via a Conan toolchain. Otherwise, you still have to configure remotes, run conan install, deal with CMake toolchain files, set CMAKE_PREFIX_PATH, etc.
With Zyn, there's no need to install or configure anything manually
Zyn:
Clones the repo
Builds it
Links it to your project
Works cross-platform, without needing the library to be "findable" in the system or Conan cache.
So in short: Zyn handles the fetch/build/link pipeline completely, using just the GitHub URL. No find_package, no system-wide installs, no registry or remotes — which makes it extremely easy for quick experiments, hobby projects, or internal tools.
We're not saying Conan is bad — it's powerful, and necessary for big projects. But Zyn aims to remove all friction for the common case.
zyntraxis · 30d ago
You're absolutely right — Conan with a conanfile.txt and minimal CMake can be very concise. And for people already familiar with CMake/Conan, that setup works well.
But here's the key difference:
> In your CMakeLists.txt, when you write find_package(somelib), that only works if the library is already installed and registered properly in the CMake package registry or via a Conan toolchain.
Otherwise, you still have to configure remotes, run conan install, deal with CMake toolchain files, set CMAKE_PREFIX_PATH, etc.
With Zyn, there's no need to install or configure anything manually
Zyn:
Clones the repo
Builds it
Links it to your project
Works cross-platform, without needing the library to be "findable" in the system or Conan cache.
So in short:
Zyn handles the fetch/build/link pipeline completely, using just the GitHub URL.
No find_package, no system-wide installs, no registry or remotes — which makes it extremely easy for quick experiments, hobby projects, or internal tools.
We're not saying Conan is bad — it's powerful, and necessary for big projects. But Zyn aims to remove all friction for the common case.
It started with a simple frustration: why do I need 50 lines of CMake or Conan config just to use a GitHub library?
With Zyn you just need to put a reference to the library in config.zyn in the [dependencies] section and boom — Zyn clones the repo, builds it, and links it to your project. No CMakeLists.txt, no conanfile.py, no manual target_include_directories, nothing.
Key Features Automatic project init (zyn init debug)
Works out of the box — no toolchain hell
Future plans: IDE project generation, CI/CD integration, Windows/macOS support
Why Zyn? Because build systems shouldn’t get in your way. You shouldn’t need to become a CMake black belt just to compile your code. Zyn is made for people who want to start fast, stay clean, and ship.
I’d love your feedback. Especially from those who’ve worked with CMake, Meson, Bazel, or Conan in real projects. Tell me what sucks, what’s missing, or if the core idea makes sense at all.
GitHub: https://github.com/zyntraxis-corp/zyn
Thanks for reading
Cloning: When you list a Git-based dependency like https://github.com/user/X in your zyn.toml, Zyn clones it into .zyn/deps.
Build Detection: Zyn looks for known build systems (CMakeLists.txt, Makefile, etc.) in the dependency. If found, Zyn runs the appropriate commands (cmake, make, etc.) to build the project.
Dependency Isolation: Zyn does not parse or resolve the internal dependency graph of project X. If X needs other libraries (Y, Z, etc.), you must also list those manually in your own zyn.toml. This gives you full control and reproducibility.
Header and Library Exposure: After building, Zyn makes the compiled .a/.so/.lib and headers available to your main project automatically by linking them via -I and -L flags.
Example:
Let’s say project X depends on Y and Z, but doesn’t use Zyn itself and just mentions this in a README. You’d do: [dependencies] X = "https://github.com/user/X" Y = "https://github.com/user/Y" Z = "https://github.com/user/Z" Zyn will fetch and build all of them. It doesn’t care that X has no zyn.toml.
And what answer did you reach? When is it legitimately appropriate? What do we lose out on by using your utility that these older tools do take care of?
Yes, Zyn started from the simple frustration of needing 50+ lines of boilerplate just to try a GitHub library. My answer was: for most projects, that level of complexity isn't necessary. So I built a tool that does the common 80% use case in 1% of the effort. One line of config, and you're ready to go.
When is CMake or Conan legitimately appropriate? Absolutely — when you're working with complex multi-platform targets, ABI constraints, custom toolchains, or need deep CI/CD and IDE integration. Those tools are mature and powerful for a reason.
What do you lose by using Zyn today? Mainly fine-grained control: custom build steps, cross-compilation, binary caching, platform-specific configs — Zyn doesn't try to solve all that (yet). It's intentionally minimal.
But here's the key part: We do plan to grow in that direction. Future versions of Zyn will support IDE project generation, CI/CD workflows, cross-compilation setups, and even plugin extensibility. The goal is to keep the simplicity, while expanding capability.
For now, Zyn is a productivity-first tool — and I think there's room for that in the C/C++ ecosystem.
I'm on my phone, and doing this entirely from memory, so I might get some details wrong (although its not too far off), but heres a minimal example of using a lib with Conan+CMake:
conanfile.txt:
[requires]
somelib/1.0.0
[generators]
CMakeDeps
CMakeLists.txt:
find_package(somelib)
...
target_link_libraries(target somelib)
Done. That's 6 lines of code, not 50. Sure, you can't use the full power of Conan with the simpler conanfile.txt, but it's a tradeoff that's fine for most simple cases.
So my question is: if we're comparing Conan's simple mode with your build system, what does yours do better?
(I definitely don't consider myself a CMake black belt)
> In your CMakeLists.txt, when you write find_package(somelib), that only works if the library is already installed and registered properly in the CMake package registry or via a Conan toolchain. Otherwise, you still have to configure remotes, run conan install, deal with CMake toolchain files, set CMAKE_PREFIX_PATH, etc.
With Zyn, there's no need to install or configure anything manually
Zyn:
Clones the repo
Builds it
Links it to your project
Works cross-platform, without needing the library to be "findable" in the system or Conan cache.
So in short: Zyn handles the fetch/build/link pipeline completely, using just the GitHub URL. No find_package, no system-wide installs, no registry or remotes — which makes it extremely easy for quick experiments, hobby projects, or internal tools.
We're not saying Conan is bad — it's powerful, and necessary for big projects. But Zyn aims to remove all friction for the common case.
But here's the key difference:
> In your CMakeLists.txt, when you write find_package(somelib), that only works if the library is already installed and registered properly in the CMake package registry or via a Conan toolchain. Otherwise, you still have to configure remotes, run conan install, deal with CMake toolchain files, set CMAKE_PREFIX_PATH, etc.
With Zyn, there's no need to install or configure anything manually
Zyn:
Clones the repo
Builds it
Links it to your project
Works cross-platform, without needing the library to be "findable" in the system or Conan cache.
So in short: Zyn handles the fetch/build/link pipeline completely, using just the GitHub URL. No find_package, no system-wide installs, no registry or remotes — which makes it extremely easy for quick experiments, hobby projects, or internal tools.
We're not saying Conan is bad — it's powerful, and necessary for big projects. But Zyn aims to remove all friction for the common case.