Cross Unified Multiplexer (C.U.M)

Yet Another build system for C/C++ Projects

Explained

Each CUM project is specified by a Project.toml file Each Project has dependencies (typically specified in deps/) specified by a Dependency.toml file. These files contain the expected *.a or *.o files. Each project is expected to have a sources and headers directory in the same directory as the Project.toml

All .c/.cpp files are compiled into .o files All .h/.hpp files are included as -isystem system headers (which has a functionality super-set of the -I argument) Dependencies that provide at least one *.a will have their libraries linked into the Project executable binary Dependencies that DO NOT provide at least one *.a will have their *.o files archived into libdependencies.a and then into the Project executable binary

Project.toml files contain Project metadata and compiler & linker arguments that can vary depending on the Platform. - They may also contain build instructions for their Dependencies Dependency.toml files contain Dependency metadata, *.a outputs, and *.o outputs. - They may also contain build instructions. These build instructions will be overriden by those specified in Project.toml if defined.

Compiler commands are generated and saved for incremental builds Linker commands are NOT generated and are recomputed every cum build run

Incremental Builds

CUM supports incremental builds for the sources and headers that it detects but not for its dependencies. When it comes to dependencies a clean build can be created via cum clean and cum build. After the first build command dependencies are no longer built. This is confirmed b checking whether or not libdependencies.a exists or not. Devs are not expected to be editing dependencies while editing code for their build targets.

Incremental builds for files in the sources directory are implemented via checking the last-modified time for entries in the compile_commands.json

The database schema can be found (here)[https://clang.llvm.org/docs/JSONCompilationDatabase.html]

Usage

Install with

cargo install cum-build

cum init <project_name> - Crate a CUM project (binary/library) cum build <project_root> - Build a debug binary cum release <root> <post_install> - Build a release binary and/or execute shell commands cum clean - Remove the build/ cache folder an execute dependency shell commands cum run [debug/release] <binary> - Build and Run the specified binary cum opts - Print Compiler Arguments

Project.toml

Platform Supports

CUM supports Windows/OSX/Linux. You can target build commands for each platform via the following pattern [Platform.<osx/win32/linux>]

Required [Platform.*] Variables

compiler = <compiler executable path>
linker = <linker executable path>
compiler_args = [...]
linker_args = [...]

Optional Variables

build_dir = <default: "buildcache/">
release_compiler = [<override the dev compiler flags]
release_linker = [<override the dev linker flags]
release_script = <release .sh/.bat script/executable>
no_confirm = <true/false>           # Enable or disable the splash confirmation dialog
all = <true/false>  # Whether or not the target should be included in `cum build` or must be built via `cum build <target>`

Install Dependencies

git/hg clone <repoistory> into the same directory as your Project.toml

[Dependency]
path = "./sdl2"

[Dependency]
path = "./glfw"

[Dependency]
path = "./glad"

Remove Dependencies

rm -rf <.deps/folder> Also remove the [Dependency] from your .toml

Targets

You can build either libraries or executable binaries. If you chose to build a library you can choose to link your library dynamically. Do note that this is a security risk and should only be done if you intend to provide your end-users with modding support or are trying to create your own bloaty Java/NodeJS alternative

[Target]
type = <lib/bin>
lib = <static/dynamic>
entrypoint = *.cpp/.c
name = <binary name>

Contributing

Install the .vimrc from ... vim -S session.vim