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.
Not really, it is not trying to replace any build system. In fact it uses itself cmake as a build system, because ourselves were users of CMake, we like it, but mainly because CMake is by far the most popular build system for C/C++ projects, especially multi-platform and open source projects. We don't say that other tools are not good, they are excellent tools too. But we cannot manage (at least now) to offer integration with them, so we chose just to use CMake. So biicode uses it as transparently as possible, allowing the user to configure things with the typical syntax we are used to with CMake in CMakeLists.txt files. You can use "configure_file", set "cmake_cxx_flags" or configure your "CTests".
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.
8 comments
[ 4.4 ms ] story [ 17.3 ms ] threadProbably 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.