coder137 / build_in_cpp

Build C, C++ and ASM files in C++

Build in CPP [BuildCC]

Build C, C++ and ASM files in C++

Aim

BuildCC aims to be an alternative to Makefiles while using the feature rich C++ language instead of a custom DSL.

Features

• Complete flexibility for custom workflows and toolchains
• C++ language feature benefits and debuggable build binaries
• Optimized rebuilds through serialization. See target.fbs schema
  • Can optimize for rebuilds by comparing the previous stored build with current build.
  • Also see the FAQ for more details on Serialization
• Customizable for community plugins. More details provided in the Community Plugin section.

Pre-requisites

• C++17 Compiler with
  • C++17 filesystem library support
  • C++11 thread library support
• Third Party Libraries (See License below)
  • Nlohmann::Json v3.11.2
  • Taskflow v3.1.0
  • CLI11 v2.1.0
  • Tiny Process Library v2.0.4
  • fmt v8.0.1
  • spdlog v1.9.2
  • CppUTest v4.0
  • Tl::Optional (master)

General Information

• A one stage input / output procedure is called a Generator with a wide variety of use cases
  • Single input creates single output
  • Single input creates multiple outputs
  • Multiple inputs create single output
  • Multiple inputs creates multiple outputs
• A two stage compile and link procedure is called a Target
  • This means that Executables, StaticLibraries and DynamicLibraries are all categorized as Targets
  • In the future C++20 modules can also be its own target depending on compiler implementations
• Every Target requires a complementary (and compatible) Toolchain
  • This ensures that cross compiling is very easy and explicit in nature.
  • Multiple toolchains can be mixed in a single build file i.e we can generate targets using the GCC, Clang, MSVC and many other compilers simultaneously.
• The compile_command (pch and object commands) and link_command (target command) is fed to the process call to invoke the Toolchain.
• Each Target can depend on other targets efficiently through Parallel Programming using Taskflow.
  • Dependency between targets is explicitly mentioned through the Taskflow APIs
  • This has been made easier for the user through the buildcc::Register module.
• Build files can be customized through command line arguments
  • Command line arguments can be stored in configurable .toml files and passed using the --config flag.
  • Users can define their own custom arguments.
  • Argument passing has been made easy using the buildcc::Args module.

Software Architecture

Interface lib dependencies

Single lib dependencies

• See also how to generate graphs using CMake

Dependency Chart

State Diagram

Generator State Diagram

Target State Diagram

See also how to create uml diagrams using VSCode

Community Plugin

• buildcc::base::Generator, buildcc::base::TargetInfo and buildcc::base::Target contains public getters that can be used to construct unique community plugins.
• Common tools and plugins would have first-party support in buildcc.
• All other tools and plugins can be maintained by individual developers.

Current state of BuildCC supported plugins

• ClangCompileCommands
• BuildCCFind
  • Host system executable
  • BuildCC Library
  • BuildCC Plugin
• ClangFormat
• Target graph visualizer (through Taskflow)

Examples

Contains proof of concept and real world examples.

Visual hybrid example graphs

Taskflow dependency for hybrid/simple example

• Build GCC and MSVC Targets simultaneously
• 1 C and 1 CPP example for both toolchains

Taskflow dependency for hybrid/pch example

• Activate PCH for GCC and MSVC Targets
• 1 C and 1 CPP example for both toolchains

Taskflow dependency for hybrid/dep_chaining example

• Chain Generator with Targets for Dependency
• 1 C and 1 CPP example for both toolchains

User Guide

Developers interested in using BuildCC

• Installation using CMake

Developer Guide

Developers interested in contributing to BuildCC

• Project internal information

FAQ

Target

• How do I supply my own custom compile_command and link_command to targets?

Serialization

• Understanding path.fbs
• Understanding generator.fbs
• Understanding target.fbs

Design/Reasoning

• Why has this third-party library been chosen?
• Why do you track include directories and header files?

Miscellaneous

• Why -Wl,--allow-multiple-definition for MINGW?

TODO

List of features to be implemented before buildcc can be considered production ready.

I would also like to request help from the Community for the following:

• Code reviews
• Design patterns
• Optimization strategies
• TODO discussions

License Dependencies

BuildCC is licensed under the Apache License, Version 2.0. See LICENSE for the full license text. BuildCC aims to use open-source libraries containing permissive licenses.

Developers who would like to suggest an alternative library, raise an issue with the license and advantages clearly outlined.

• Fmtlib (Formatting) [MIT License]
• Spdlog (Logging) [MIT License]
• Tiny Process Library (Process handling) [MIT License]
• Taskflow (Parallel Programming) [MIT License] [Header Only]
  • See also 3rd-Party used by Taskflow
• Nlohmann::Json (JSON Serialization) [MIT License] [Header Only]
• CLI11 (Argument Parsing) [BSD-3-Clause License] [Header Only]
• CppUTest (Unit Testing/Mocking) [BSD-3-Clause License]
• Tl::Optional (Optional support) [CC0-1.0 License]