Busy Bees

C++ did not receive much love in the past. Now its time for the bees to take over.

In the recent years we've experienced quite some improvements in the C++ language. Nevertheless, one thing that was still behind was dependency management. Anyone who wanted to compile an existing project knows that problem: As a matter of fact there is always at least one lib missing. This is usually the point where things get messy:

What version of the library?

Is it supported for the desired platform anyway?

Do I need to compile it from scratch?

Is it just a bunch of headers? Do they need to be compiled or transformed?

Does the library itself have some (unresolved) dependencies?

Quite often I found myself struggling to get all dependencies in place. Sometimes that might consume as much as several hours of my time. In some rare cases I even gave up considering potential time loss vs gain by building the application.

I am happy to say that these times seem to be ending soon. The busy bees at Biicode are working on a C/C++ dependency management tool. Currently the tooling is already quite advanced, with a webpage that can be browsed to find interesting projects or get some documentation.

So what was my first experience with Biicode? As a platform I've picked my Xubuntu system. I had to download the Debian 64 package. Installation was easy and straight forward. Just for the sake of exploration I also tried Biicode on Windows. Here I had to install CMake as well. Apart from that the major obstacle was to avoid MinGW. In the end two things had to be done to use Biicode with Visual Studio:

Open a Visual Studio command prompt (or include all required paths) [usually this is called something like "Visual Studio (x86) command prompt"]

Coming back to Linux I tried to create a new Biicode project. That is fairly simple and follows the getting started guide word by word. However, going beyond the simple example of using a mature block as dependency proved to be a bigger problem than I thought. The issue that I faced was that dependencies were discarded and therefore not downloaded.

Not very funny, huh? Needless to say that bii build will therefore also fail.

What's the problem here? Obviously development versions are always discarded. By default (if no requirement is provided by us) the latest stable version picked. However, if no stable version is available, then the development version should be picked. As we've seen, this is not the case. But there is one way out: Requiring the development version.

Aside from the described problems everything was mostly straight forward and a pleasure to use. The bii command is a universal tool that interacts great with CMake. The latter, however, is still omnipresent. For instance if we want C++11 (and of course we want that) we need to manually edit the CMakeLists.txt. If we want more compilation options we also need to edit the CMake configuration directly. Therefore Biicode seems to be a little bit too strongly coupled to CMake. And learning Biicode also requires learning CMake.

I am quite sure that the tooling will evolve and all those small hiccups will be resolved eventually. I think it's safe to say that I couldn't be happier with this movement! A capable dependency management tool is worth something. All new languages come with an integrated solution. I could not emphasize enough, e.g., how important NuGet is for the .NET ecosystem. Thanks to the busy bees at Biicode for providing such an outstanding and well-thought solution!

Update

What I missed is to explain yet another approach for taking development versions. It is possible to control the find policies on a per-project basis. That way we can take development versions of any trusted source, like our known colleagues.

We find the project specific rules in the bii/policies.bii file. We just have to add lines similar to