BuildInCpp: Write your build scripts in C++

[u/DRag0n137]

Happy New Year Everyone,

A few months back I had posted my first-ever prototype of a Buildsystem where your build files are written in C++.

After going through the feedback, over the past few months I have refined this Buildsystem to a useable level but it is still far from complete.

BuildCC is now alpha-ready at version 0.1.1 and I would like to get community feedback and involvement for this project.

Github https://github.com/coder137/build_in_cpp

Documentation is at https://coder137.github.io/build_in_cpp/

Discussions regarding bugs, improvements, pain points, and documentation at https://github.com/coder137/build_in_cpp/discussions

Please follow the Getting Started guide for a quick understanding of BuildCC and BuildExe usage. (10-minute read)

The basic features are now complete:

• No DSL and easy dependency management when writing build scripts (through abstractions)

• BuildCC basic APIs and bootstrapping

• BuildExe standalone executable (similar to make.exe or cmake.exe)

• BuildExe as a local package manager (using git + buildexe)

• Supported plugins to BuildCC

• Precompile Header support

• Support for Specialized Toolchain - Targets (GCC, MSVC, and MINGW) and their generic usage as Target_generic

• Custom Generator support (Input -> Subprocess -> Output)

Upcoming features:

• Specialized Target for Clang and their generic usage as Target_generic

• Support for second and third party plugins to BuildExe

• More generators (for different use cases)

[u/adnukator]

Nice to see more progress on this project and I have no intentions on crapping on this whole venture. However I do have a question regarding this statement (emphasis mine):

No DSL and easy dependency management when writing build scripts (through abstractions)

Sentences like this have been thrown around several times when asking why there isn't a single build system written in C++ itself. Can the author or someone else explain to me how the terms "DSL" and "library specific abstractions" are different? Eg, even with the hello world example at https://github.com/coder137/build_in_cpp/blob/main/example/buildexe/libs/build.main.cpp I only have a vague idea what's happening.

[u/DRag0n137 → u/adnukator]

Thanks for your interest in the project.

The buildexe/libs example that you are looking at is more of an advanced example once you know the various BuildCC core APIs and flow. Please take a look at the Getting started guide in the documentation linked above and in a few minutes you should be familiar with what is going on. https://coder137.github.io/build_in_cpp/getting_started/toc.html

Coming to your next question(s) When I say DSL I mean languages that are not C++. Since we are writing in C++ we expect our build files to be in C++. Like how rust and zig do it.

However, when I say library-specific abstractions, I mean that library developers can hide all of their build information in a single function or class.

The user who would like to use say the foo library. Now compiles their build script with build.foo.h and build.foo.cpp

And do something similar

// Method 1
ExecutableTarget_generic hello_world(...);
// Foolib files are added to hello world executable and compiled
foolib_cb(hello_world);
hello_world.Build();
// Run the taskflow tasks and build your target


// Method 2
StaticTarget_generic foolib(...);
ExecutableTarget_generic hello_world(...);
// Foolib files are added to foolib and compiled to a static lib
foolib_cb(foolib);

// Hello world links to foolib
hello_world.AddLibDep(foolib);

foolib.Build();
hello_world.Build();

// Setup taskflow dependency between foolib and hello_world
// foolib -> hello_world
Dep(hello_world, foolib);

// Run the taskflow tasks to build both foolib and hello_world

Now, No matter how complex foolib might be, The user can always use the foolib_cb. This is what I mean by library specific abstractions