Transpiler for Build Systems - Unifying C/C++ build logic

Transpiler for Build Systems

1. Introduction to this talk will be about the current nature of project management and build system environment in a typical C/C++/Fortran project, just as a general overview
2. Upon discussing the plethora of options and the king of hill (cmake), I will then delve into the problems of popular choices (like cmake, ninja, meson, gn, make) and showcase the “pick your poison” situation when it comes to choosing a build system or generator.
3. I will then proceed to illustrate my solution - a high level DSL that has a simple purpose: to be declarative, simple and incredibly effective language that can be transpiled into a specific build system syntax and semantics.
4. The above point itself will not convince anyone, as every build system works differently and if we look into the spec of each one, each serves a different purpose altogether. I will dive into this deeper by showing the stark differences between each build system/generator (ex: cmake is turing complete - why is that required for a build system? Ninja isn’t meant to be handwritten by a human or meant to be used singularly and so on) and mainly focus on their semantic differences. Reconciling them is a task for sure but here is where I introduce the crux of the project - language subsetting or cross-cutting, understanding the design of each backend (build system) and the semantic logic that can be transpiled by the DSL itself.
5. This section will talk about the key aspect to any build automation tool - the build graph and primitive directives used to configure the build itself (think link options, compile options, include directories, source files, adding compiler flags, etc.). These are a universal concept to any build tool that serves a C/C++ project as these are options you can put through the compiler itself. As such this is the core part of the DSL that can be transpiled into every backend regardless of the language semantics. The rest of the DSL is “selective” in nature so to speak. Certain features like variable assignment and conditional blocks are not possible to be transpiled to every build system syntax (ex: ninja) and hence such code will either be dropped or will undergo semantic or backend specific passes (ex: constant folding) to attempt at reconciling the code (similar to how cmake being the ninja generator flattens code the same way). Note that I will demonstrate my own project “Melon” while explaining this section
6. In the final segment of my talk where I introduce a broader plan, called tibs (transpiler infrastructure for build systems) wherein I intend to add build hooks (pre and post build), package management, central binary for formatting and linting (via clang tools) and managing a C/C++ project’s lifetime through this transpiler (the goal is to mimic the ergonomics of cargo or dune) with extensions to package repositories like conan and vcpkg.

1. Understand what a transpiler is and basic overview of a compiler infrastructure upto the IR
2. Learn about the perils of handling a C/C++ project and its build lifetime in a non-unified environment
3. Learn about existing meta build and core build systems and their semantic differences along with their use cases
4. An original idea on how to unify this environment with minimal project restructuring
5. Deep understanding of the Melon transpiler and how it handles the build graph, semantic and backend passes, memory profiling and diagnostics.