Currently most of the buildsystem logic is located in ruby (rake) files. A lot of this logic is however generic for packages in any language, like installing etc or lib files to package repositories, keeping track of corto library, keeping track of source location etc.
To avoid duplication of code when modularizing the buildsystem for different programming languages, this generic functionality should be implemented in a single "builder" package. This package should follow the same pattern as a generator, in that it captures all relevant information of a build, and then invokes a language-specific implementation which actually does the building.
In this new design, there are three components:
The builder framework: captures information about a build & invoke implementation
A builder interface: the interface invoked by the builder framework that performs the build
The builder runner: the underlying tool that generates the commands (make, rake, ...)
Implementations of the builder interface will take care of code generation and invoking the runner.
To prevent further duplication of code, the builder shall also be able to build the corto library itself. This prevents having to maintain builder logic in multiple locations. This does however mean that the builder needs to be built before corto. To prevent having to write operating system abstraction functions twice (file/directory access, copying/removing files etc) common abstraction functions will be separated from the runtime so that the builder can use them before building corto.
Currently most of the buildsystem logic is located in ruby (rake) files. A lot of this logic is however generic for packages in any language, like installing
etc
orlib
files to package repositories, keeping track of corto library, keeping track of source location etc.To avoid duplication of code when modularizing the buildsystem for different programming languages, this generic functionality should be implemented in a single "builder" package. This package should follow the same pattern as a generator, in that it captures all relevant information of a build, and then invokes a language-specific implementation which actually does the building.
In this new design, there are three components:
Implementations of the builder interface will take care of code generation and invoking the runner.
To prevent further duplication of code, the builder shall also be able to build the corto library itself. This prevents having to maintain builder logic in multiple locations. This does however mean that the builder needs to be built before corto. To prevent having to write operating system abstraction functions twice (file/directory access, copying/removing files etc) common abstraction functions will be separated from the runtime so that the builder can use them before building corto.