Okay, so let me tell you about getting Conan working here in the office. It wasn’t exactly smooth sailing, but we got there.
It all started because managing our C++ dependencies was a real mess. You know how it is. We had libraries checked into the main source code repo, different versions floating around on different developer machines, build scripts that were pages long just listing include paths and library locations. It was fragile. Every time someone needed to update a library, or a new person joined the team, it was hours, sometimes days, of pain just getting the project to build.
I’d heard about package managers for other languages, like Python’s pip or Node’s npm, and always thought, “Why can’t C++ have nice things like that?” Then I stumbled upon Conan. Seemed promising. So, I decided to give it a try on my own machine first, just for a small side project we had.
Getting it installed was easy enough. Just a pip install command. Then I started playing around. Figured out the basics: how to write a to list the libraries I needed, like Boost or Zlib. Ran `conan install .` and watched it download the pre-built binaries. Magic! It just worked. My little project built cleanly without me manually downloading anything or messing with project settings too much.
Trying it on a Real Project
Okay, personal success is one thing, but the real test was our main codebase. This thing is big, with lots of internal libraries and some weird third-party stuff. I picked one small component of the main application first.
- First step: Identify all the external dependencies for that specific component.
- Second step: See if ConanCenter (their public package repository) already had them. Most common ones like Boost, OpenSSL, Zlib were there. Phew.
- Third step: Create a this time, a bit more complex than the text file, because I needed more control over options and settings.
- Fourth step: Run `conan install . –build=missing`. This was key. Sometimes the exact binary for our specific compiler version or settings wasn’t pre-built, so this told Conan to just build it from source if needed. Took a while the first time for some libraries.
After some fiddling with compiler settings and options in the conanfile, I actually got this component building using dependencies fetched by Conan. It felt like a massive win. No more hunting for library files!
Getting the Team On Board
This was the tricky part. People are used to doing things the old way. Showed my little success to my manager and a couple of teammates. Some were skeptical. “It’s another tool to learn,” “What if the Conan server goes down?”, “How do we handle our own internal libraries?” Valid points.
We had a few meetings. I argued that the time saved in the long run, especially for onboarding new people and ensuring consistent builds, would be worth the initial learning curve. For internal libraries, I explained Conan lets you create your own packages. For the server issue, I proposed setting up our own private Conan remote repository right here on our network. That way, we control it, and it’s fast.
Management eventually agreed to a pilot. We decided to set up a simple Conan server using the free `conan_server` tool provided by Conan itself. It’s basic but does the job for a small team. Installed it on one of our internal servers.
Then came the work of packaging our internal libraries. This took some effort. Had to write recipes for each of our shared components. This involved figuring out how each library builds, what its dependencies are, and how to properly package the headers and compiled binaries. Lots of trial and error here. Debugging build failures within the Conan cache wasn’t always fun, I’ll admit.
The Outcome
So, where are we now? We’ve migrated most of our core projects to use Conan. New projects start with it by default. Is it perfect? No. We still occasionally hit weird edge cases, especially with complex build systems or older libraries. Learning how to write good Conan recipes took time. Setting up the CI/CD pipeline to work smoothly with Conan installing dependencies also had its own set of challenges.
But overall? It’s way better than before.
- Builds are much more consistent across developer machines and the build server.
- Adding or updating a dependency is usually just changing one line in a conanfile.
- New developers can get a project building much faster. Clone the repo, run `conan install`, build. That’s the dream, and we’re much closer to it now.
- Our main source repo is cleaner without all those third-party binaries checked in.
It was definitely a process. Took time, effort, and some convincing. But looking back, tackling that dependency mess with Conan was one of the better infrastructure decisions we made here. It wasn’t just downloading a tool; it was changing how we thought about building our C++ software. Worth it, I’d say.
