Why a FILE BASED dependency manager rocks for C/C++

We have a big problem. We have miserably failed to explain the core value proposition of biicode: a file-based dependency manager. We have tried to communicate it in the homepage, in features landing pages, videos, etc. While we certainly are growing, it is also true that not as fast as we would like.

There are many reasons that explain this: People understand that we are a dependency manager for C/C++, but also realize that we still don’t have premium accounts (for private code), in-house deployment or that we’re not open-source. This is all true, we are working in all these features, including going open-source regarding which we will soon announce something relevant. But we think these are not reasons (stoppers) enough to not engage with the platform now, try it, check how it works, give feedback to help define the tool to your needs.

We believe that the main problem is that we didn’t explain properly what makes biicode so special, and we failed because we have used the wrong channels. Here, I will explain it with the language we, developers, all love: source code.

C/C++ dependency manager

Hands into the file-based dependency manager

I have recently written about how to use ZMQ and protocol buffers with biicode. Here I will develop a client-server application which components can be very easily reused individually in new projects, without having to write a single line of configuration or having to worry about packaging or installing. [If you want to try it on the go just download biicode HERE]

Stop talking, show me the code!

client.h

client.cpp

The person.pb.h and person.pb.cc files are generated with the “protoc” binary from the person.proto, as explained in our docs.

person.proto

We will create a simple client application that just creates a Person object, serialize and send it to the server.

clientapp.cpp

 

The server application will continuously receive Person data from clients and send them to a SQLite database.

severapp.cpp

with the server being:

server.h

server.cpp

Building all this code is pretty simple and can be done with biicode without any configuration, remember to generate the person.pb files with “protoc”, check the documentation here.

So far, biicode is a “smart” dependency manager, that figures out which dependencies it needs from #include directives (of course, you can also define them in requirements.bii file). In this case, ZeroMQ, protobufs and SQLite.

But the key point is not that. It is how easy you can reuse individual components from this project into new projects, how simple you can share it with the world without having to worry about packaging or installers. The first step is to upload to biicode:

This command will create a DEV version (which means that it is not frozen, you can overwrite it; there are other BETA, STABLE tags that freezes a version) in biicode, you can go to www.biicode.com/yourusername and check it.

Imagine that the server side is developed to run only in X systems, but it will not build in Windows, due to some non portable code. In this example we have used SQLite which is portable. In any case, it is clear that if we want to develop a new client application we do not need to build the server or depend on SQLite at all. Lets build such a client:

Copy the following code inside the “blocks/yourusername/newclient” folder:

yourClientapp.cpp

And execute:

Let’s explain what a file-based dependency manager is

Now the key point! Go to the project “deps” folder, and check what is there: There is no server code, and there is no SQLite code!! And we have done it without a single line of configuration. How is this doneC/C++ file-based dependency manager ?

Biicode is a FILE BASED dependency manager. That lets amazing things to happen, such as allowing to reuse individual files from previous projects without having to worry about packaging, setup or installs. Biicode tracks which files depends on which files, and use it to automatically define build targets, or manage dependencies accordingly. For example, you could just reuse the “Person” object from the previous example in another project, and you will not depend on ZMQ or SQLite at all, as those files do not depend on them. And this is only the beginning, with this file based approach you can also do many other amazing things, stay tuned for next posts.

We believe this is indeed a new paradigm for dependency management. We are still in beta, releasing based on our users feedback almost every week, towards such a system that could rock for all of us as developers. That means that we are not perfect, as I told you we are working hard and defining the best possible roadmap for our community, including open-sourcing the code and building all the necessary tools for production environments.

Help us improve, try it out

Get started Now

If you feel that this makes sense, give feedback, spread the word as much as possible.

Stay tuned


Related Posts