biicode knows how source code files connect to each other. With this information, it creates a boilerplate CMake layout to build your project automatically. biicode then detects how sources connect and builds a dependency graph following #includes and implementations generating, for each block, a CMakeLists.txt defining variables to the dependency graph detected.
This translates into a CMakeLists.txt file with just one line by default:
Even though the boilerplate might be enough for some projects, here’s a guide to fully control the building process.
Today, we explain the different options available in biicode once you’ve got your CMakeLists.txt ready.
We talked about our old Terms of Service in a previous post and we explained then why we hadn’t paid enough attention to them while the developing the tool. The latter has evolved and added such degrees of complexity that the legal support for the users and the company needed a rethink and a rephrasing to say the least. And that’s exactly what we did: after consulting with our legal counselors and talking to companies that provide similar services, we have revamped the ToS, check the new ones here.
We have decided to move out of beta some of our coolest features and allow any user enjoy them. Today we are featuring git remote linking and block collaborators management but we release every two to three weeks so expect new features like these coming every fortnight or so. These functionalities are now available to all biicode users. Enjoy! you can always suggest or upvote the existing features that are ahead in our roadmap here.
This post summarizes the lessons learnt from adapting the CppMicroServices framework to a biicode compatible format. It does not go into detail about the actual modifications, but focuses on the lessons learnt adapting the framework.
CppMicroServices is an implementation of the OSGi framework, which enables runtime dependency injection. Modules of code (bundles) can be loaded and unloaded at runtime. In the case of CppMicroServices, bundles are either shipped in the form of shared libraries, or statically linked into the executable.
Based on packaging principles, bundles should be packaged and released separately – so that they can be depended on individually. biicode’s dependency management through blocks is suitable as a dependency management tool that supports this flow.
Biicode is not a Version Control System, neither a Source Code Management System. As a dependency manager, biicode makes “some kind” of internal version control to establish dependencies against a specific version of the block.
Our versions are incremental integers starting on 0. Until now, to know that biicode’s version corresponds to any official version you had to look for it on the block’s description or readme.
Now you can tag a version while publishing. For example, qiangwu/atlstl corresponds to the official “1.9.98” version:
A few days ago, we came across this fantastic library from the Dropbox team, to encode and decode JSON using C++11. Syntax is very clean and attractive which makes the library very easy to use.
Also, this library is an ideal example to show how to upload to biicode your library like I did.
Why would you want to upload to biicode your library ?
Once it’s uploaded to biicode, everyone (including yourself) can reuse it easily and without any complex configuration.
This is key: If you make a good job configuring and uploading the library to biicode, nobody will EVER do this job again. The library will work for anyone just by typing #include “lasote/json11/json11.hpp”.
JSON11 by DROPBOX
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.
Yesterday biicode suffered a DDoS attack on this wordpress blog.
DDoS attack (Distributed Denial of Service) tries to make a resource (this blog) unavailable using servers distributed all over the world.
In this case, sources came from Korea, USA, Europe… More than a hundred simultaneous connections brought down our blog.