Because C++ does not have a standarized package manager it resulted in multiple tools being created in parallel.

One of these tools is Conan which I've decided to use for all my projects starting around 2018. (if not earlier)

Quick History Lesson​

This part is entirely my own experience, it might not fully reflect the history of the tool ;p

Initially when conan was released to the public (and was already stable enough for usage) it was one of the first solutions that provided a flexible and powerful enough definitions to handle C++'es various build tools, toolchains, platorms, standards and anything else that might introduce ABI incompatibilities.

While version 1.0 of Conan did allow features like multi-config packages (which was a feature mainly for Visual Studio projects), creating the packages themselfs was much more complex than nowadays.

Not only does Conan v2 support many more tools like CMake or Premake, it also provides a lot of utilities to build your own recipe / generator extensions.

Public recipes​

Now getting to the crux of this post, the state of public available recipes found on Conan Center.

Unless the recipe is header-only, almost none of them work out of the box.

• You either need to install yet another build tool on your os.
• Change direct dependency versions to a value that another dependency requests indirectly.
• The recipe itself does some weird logic instead of just running the build tool.

Whi is this happening, what's the reason you ask?

It's the CRIMINAL underutilization of the version ranges and tool_requires features and sometimes misunderstanding of the build tools.

Versioning done better​

While I admit, resolving versions between multiple recipes may even become impossible depending on the complexity at least a few general approaches should be considered.

Version Conflicts​

While it is a bad idea to have your final project use version ranges, I would argue that any dependency inside a conanfile.py should almost always use version ranges.

With a requirement on tool_requires dependencies, but more on that in a moment.

Imagine we have a dependency on LibraryA version 1.12.13. Because we provided the version value directly, it will always resolve the package to that specific version. No other versions will be accepted.

While this does not create an issue in isolation, it can become a problem if two or more packages use different versions of the same dependency.
Project -> LibraryA/1.2.13
Project -> LibraryB/0.2.3 -> (intermediate) -> LibraryA/1.2.15

Now Conan run into an issue, because LibraryB specified its dependency on LibraryA with a specific version, we have a conflict. Which version should we use?

While Conan provides a way to force a specific library version we are not looking into this approach today.

What we want is for libraries to select a version range on their dependencies.

Version ranges​

Conan alows us to specific a range of compatible versions for a dependency, this uses square brackets [...] notation to do this. For example LibraryA/[>=1.2.0] will accept any version of LibraryA if it's higher or equal to 1.2.0.

The requested version stings are reported by Conan during dependency gathering, giving the consumer valuable information about two things:

1. The library with this dependency is aware of upcoming versions and is probably prepared to deal with that fact.
2. If a version conflict actually occurs on a version range, the probablility the packages are actually incompatible is high.

Lets check out usage with ranges: Project -> LibraryA/1.2.13
Project -> LibraryB/0.2.3 -> (intermediate) -> LibraryA/[<2.0 >=1.2]

Here LibraryB has a version range on dependency LibraryA, it will accept any version above 1.2.0 and reject everything from 2.0.0 and higher.
This does assume LibraryA follows semantic versioning to the letter, but it's still better than brute-forcing your desired version and hope for the best that LibraryB will accept your version as is.

However, as mentioned previously, using version ranges on your final project does not make sense, as you should target a single version. Ranges should be used only by packages that are expected to be consumed as dependencies themselves.

If you specify a version range on an actual final project, now you lost all control or reasoning about what your program may do, since the version is not directly set and may change any time.

Do not assume my Environment!​

I think the worst part of public dependencies is, that they assume I have every single build tool installed on my workspace.

With just a few popular dependencies, you will be expected to have installed the following: CMake, Autotools, Make, Ninja, Premake, Mason and probably something else...

Not only do I not want to deal with installing any of these tools locally, I don't even want them to show up in my terminals autocomplete...

So how do we build without having the tools? Well, Conan provides a pretty good feature for this, which is called tool_requires.
This simple property allows you to specify dependencies required ONLY during building of your library. So if you are only downloading the ready binaries and Conan is generating the compiler arguments for your own project, these dependencies will not be part of that.

In addition, Conan allows packages to export executables, so when we put both together, it's easy to understand that we can request the desired tools like CMake or Ninja during package builds, and not deal with them if everything is already available.

Quick How-To​

Lets circle back to our example from above. Lets say we have the following setup

Project

• Requires: LibraryA, LibraryB
• We use CMake locally to build our project

LibraryA

• Requires: nothing
• Uses: CMake

LibraryB

• Requires: LibraryA
• Uses Premake5

Now if we do NOT use the tool_requires feature and LibraryB does not provide a ABI compatible binary, we now are forced to install Premake5 on our system, setup paths to be discoverable by Conan and hope that the version of Premake we use is compatible with the script the dependency expects...

I say "No! Thank you..." to this, it's pain in the ass and I don't want to understand your tool.

Now lets say the package has properly set up it's tool_requires property:

LibraryA

• Requires: nothing
• ToolRequires: CMake/[<4.0 >=3.20.0]

LibraryB

• Requires: LibraryA
• ToolRequires: Premake/[<6.0 >=5.0.0]

Now if we lack the build binaries, Conan will download the expected tools within their expected version ranges and build them for us.

As long as the tool is avilable as a Conan package (in most cases they are) this makes dependency management much smoother.
Especially if a library provides version ranges for the tools it uses, now multiple packages can very probably decide on a single necessary CMake version reducing storage usage but also ensuring correctness.

Summary​

The fact that, to this day almost a decade of Conan being accessible, I still see recipes not using tool_requires is astounding...

It makes it almost impossible to rely on public recipes, because to use them I need to spend half a day installing the desired tool.

Maybe once someone actually starts reading my blog posts, this will change, but until then, I'm stuck with making my own recipes for all the dependencies I want or need to use.

Links​

• Conan (Website)
• Conan Center (Packages)
• Conan Docs (Website) - versions, build_requirements / tool_requires

And yet, there are topics I've not even started looking into...

While I've had multiple attempts at running my personal NAS / VPS setups, hoping to host a cloud storage, mailbox, website or block. It always ended up tragically.

Not only because I've had lack of understanding why secured connections are a must, or how to setup a firewall.

A lot of problems came from the fact I've had little to no understanding how applications actually bind to networks, how ports are used and how to even make it possible for multiple services to be hosted from a single machine. (network*)

My first exposure to docker was due the Nginx-Proxy project. I've been researching (probably a third time) how to setup multiple services on multiple sub-domains. This project also introduced me to the concept of Let's Encrypt Certificates

And thus I've installed docker for the first time on my VPS.

First steps​

In short, I found docker complicated...

The example command lines looked scary, the parameters short and not really self-explanatory, especially when I understood the -v parameter be a short form of --verbose, which often is the case, right?

Without really udnerstanding what a container is (since I had no particular interest in HOW it works, but IF it works), I've started testing... A lot of testing...

Shortly after I found people using yaml files, called docker-compose.yml, this peaked my intetest... It looked, clean.

Docker compose removed the cryptic parameters of the Docker CLI and gave structure to something I've not undersood much yet. It was some kind of savior, from actually reading the nitty-gritty details in the Docker documentation.

Volumes, Environments, Networks, and more...​

While I was able to setup a few services with just docker compose, some pre-shared configuration files and following basic steps telling me to set THIS_ENV_VAR=I'm your father! it was far from good.

Environment Variables​

The bread and butter of Docker and even more Docker Compose. Variables are used to control various aspects of a container, starting from setup values down to controlling behavior betwen restarts or upgrades.

Value can be specified directly on the CLI / docker compose file, or can be indirected with values from a .env file.

Volumes​

On the surface, simple, easy to understand, nothing complex going. You take a part on your host and map it to a path on the container. Why do we do this? Just to access files?

Well, yes, BUT^t volumes are also used to preserver state between container upgrades. They can also server the purpose of sharing files between containers by mapping the same (external) volume on multiple containers.

While in most cases (let me ballpark a value of 90%) you don't need more than mapping a few volumes to a single container, the feature allows for far more configurations.

mostly because I've had no idea of actual web-security, why it matters to have your site served with a secured connection, how to properly host multiple services from a single network

Networks​

Oh boy... Is this a rabbit hole on it's own, and not just because of Docker, but in generall how networks are designed, how information is passed between connected clients and how easy it is to get lost.

One of the most underdocumented or rather, under-advertised features in my opinion is the possibility to assign subnets directly and mark them as internal.

With just this you can make a lot of containers much safer, by closing them off from the world but also be able to assign IP's to some expected values.

I might go over this topic based on my personal setups in the future.

Others​

I've so far just scratched the surface, there are many other configuration surfaces that docker exposes.

And this does not include the features that connected containers can provide...

Nowadays​

At this point I've fully embraced the usage of Docker, not only for hosting a website or service, but also to run various CLI tools.

The ability to simply attach parts of workspace to a container, and execute the a tool installed inside it is something truly amazing.

Right now I'm generating doxygen files and this website using this approach. The repository contains only the content, while the container keeps all node dependencies and scripts.

Since both Doxygen and and Docusaurus produce static files that can be hosted without all the source content and node scripts, that's what I'm doing.

Links​

• Docker (Website) - Envrionment Variables (Compose), Networking (Compose), Storage
• Doxygen (Website)
• Docusaurus (Website)
• Let's Encrypt (Website)
• NGinx Proxy (GitHub)

Back then I've just played with the idea of anoying the general public with some of my views and opinions.

Recently I've started working on moving the whole project to a self-hosted ecosystem, this includes:

• A git repository with interface (ForgeJo)
• A CI/DC server (TeamCity)
• A project system for issue tracking, documentation, etc... (YouTrack, currently hosted on JetBrains)
• A OCID provider (KeyCloak)
• A translation service (Accent)
• And more...

With this endavor slowly taking it's final form, since most of these are already configured, secured and already running for the past few months, I'll now share what I've learned.

Don't expect any regualr schedule on these blog posts but I should be more often that 2-3years. At least until I'll get busy again with real-life issues.

Stay safe, and don't get consumed by the AI craze. Knowing is king!