C++ - Reddit

lier than me and hid all their stuff behind `clang++` executable. Anyways this is where I think we should start counting our tools: **Toolchain Abstraction Tool**.



The second part is resolving dependencies. TUs consume modules, module consume modules, all that. Basically speaking, if modules stuff is represented as files, we can explicitly feed those files in invocations where they are needed. Then ordering invocation is "trivial". Well at the very least in context of state-of-the-art contemporary systems: we already do this with headers. Needs some tweaking at most.

What deserves much more attention is optimization techniques. Currently we have 3 (correct me if I'm wrong):

* Parallel command execution. Will not go anywhere, although will be a little bit more tricky.
* Incremental builds. Always watching over us.
* Databases of precompiled files. Newcomer. Problematic to integrate as it stands now.

To manage all this we can have another tool: **Script Execution Tool**.



Next comes configuring our project. **Project Configuration Tool**. Part of CMake fills similar role, and you can easily witness how screwed up everything is when you are trying to support multiple targets and multiple toolchains.



**File Management Tool**. Tucks your files where they need to be, fetches from internet, didn't give it enough thought, something else?



So overall we can round up the zoo to whole... **five** tools:

1. **Toolchain abstraction tool**
2. **Script execution tool**
3. **Project configuration tool**
4. **File management tool**
5. **Virtual environment management tool**

Yes, I added a fifth one, but everything in order.



**Toolchain Abstraction**

Responsibilities:

* Define and provide unified "high"-level toolchain invocation commands (similar to listed above) and transform those into toolchain-specific ones. Yes I also cringe at unified, but let's *temporary* agree on something at least.
* Provide similar support for various widely used compiler switches (optimization nobs, warnings, `-fno-rtti`, other fun stuff)
* Bring toolchain switching down to change in one flag.
* Provide query API for various features (like "do you have asan?")
* Toolchain verification. I've seen CMake and autotools do something like this, but a tool which is more closely related to the subject will probably do better?
* Toolchain versioning. Maintain multiple versions, tool selections (ld vs gold vs...), standard libararies (clang has access to full 3), custom patches and whatnot - without destroying any of your projects.
* Produce/consume *toolchain description scripts*.
* Provide helpers, explanations and search over supported options, information about toolchain support/compliance. I feel like compiler options explanations are often as cryptic as flags themselves. And yeah, don't forget, there are new people too, for them modern toolchain is just black magic box as it stands now.

**Script execution**

Responsibilities:

* Takes a script which contains a list of tool invocations. Assumptions: 1) no specific order 2) each invocation is tool+config flags, input files, output files 3) as long as tool is the same, config is the same, input is the same = output is also same
* There are no conditions or configuration at this step! Adding this makes many features much more difficult to correctly implement. Also it happens right after project configuration. Need something - put it there.
* 2nd point provides a way to infer dependencies between files and therefore order in which commands must be executed. And no, specifying order doesn't achieve much since if we want to split the work over multiple threads, to do it correctly we need to build dependency graph anyways.
* 2nd point is also a reason to have modules build as separate invocations (so we can tie module object files, module body/interface and TUs that consume it). Btw its also a reason *to have module files to be explicitly specified in invocation instead of letting toolchain to infer it magically.* This way we can employ power of dependency gu

9 views08:23