I think biicode is trying to do (better) what autotools, cmake, and SCons do. So comparing to them might be useful.
And if it is not trying to do replace those tools, explaining that might be helpful.
Probably the post fails to explain that what biicode does is to generate basic xxx_vars.cmake files that contains useful variables about the project, and also a CMakeLists.txt (in case it is not defined by the user) which has some biicode macros that help to define the build. You might be able to read about it here: http://docs.biicode.com/c++/building.html
What biicode tries to do is to complement, and fill the voids that build systems were not designed for: - Storing code in a central server repository. Later retrieving code from the repository. Handling dependencies per project, not per system. - Managing different versions of dependencies, managing conflicts of dependencies and allowing conflict resolution. - Allowing easy discovery, retrieval and updating of dependencies. Offering web access to the code.
These are more or less the typical features of dependency managers (as PyPI-pip, NPM...). Biicode tries to go one step further by eliminating almost completely the packaging, the user does not have to think about libraries, setups, installs, updates... and this can be done thanks to the file based approach.
I hope it is better explained now. Thanks very much for your comment, do you think it is worth to edit the post with these ideas? Any further suggestions are very welcomed.