rtm use case
build was developed around a set of libraries and tools, commonly refered to as game engine or framework.
Here is a structure of a game engine (rtm) for which build was initially created:
📂 rtm
📂 3rd
📂 build
📂 data
📂 doc
📂 src
📂 game
📂 games
📂 libs
📂 libs
📂 tools
📂 cmdline
📂 libs
📂 qt
📄 README.md
📄 buid.lua
But rtm is a hobby project and at the moment only bits and pieces of it are made open source. Idea is to be able to distribute any project from the engine without having to distribute much else, this is what build makes very simple.
Probably the best example is MTuner (a C/C++ memory profiler) that is one for the ‘Qt based projects’ from the directory hierarchy above but is also distributed as a stand alone project. Here is all that is needed to specify MTuner project and its dependencies:
This is enough to load MTuner as a project in a bigger solution(s) and add its dependencies.
build relies on a Lua language feature to check if a function exists by it’s name. This is why we have a common prefix for most actions and a suffix which is the name of a project. In this particular instance we have, for example, dependency declaration function projectDependencies_MTuner which will be called to retrieve the list of dependencies during loading of the project.
The solution for MTuner loads a few more projects:
Each of the projects in rtm is setup in this way, each has a project-named lua script for build and an additional genie.lua that allows it to be a stand-alone solution.