cortoproject / corto

A hierarchical object store for connecting realtime machine data with web applications, historians & more
https://www.corto.io
MIT License
87 stars 14 forks source link

Move buildsystem functionality not specific to language bindings to builder library #623

Closed SanderMertens closed 6 years ago

SanderMertens commented 7 years ago

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:

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.

SanderMertens commented 6 years ago

Resolved when switched to bake buildsystem