[bogwog]

> 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]

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.