<commit_before># Regenerating project files

Prerequisites
- `python`
- `pip install mako` (the template processor)
- `pip install pyyaml` (to read the yaml files)
- `go` (required by boringssl dependency)

```
# Regenerate the projects files (and other generated files) using templates
tools/buildgen/generate_projects.sh
```

# Quick justification

We've approached the problem of the build system from a lot of different
angles. The main issue was that there isn't a single build system that
was going to single handedly cover all of our usage cases.

So instead we decided to work the following way:

* A `build.yaml` file at the root is the source of truth for listing all the
targets and files needed to build grpc and its tests, as well as a basic system
for dependency description.

* Most of the build systems supported by gRPC (e.g. Makefile, cmake, XCode) have a template defined in this directory. The templates use the information from the `build.yaml` file to generate the project files specific to a given build system.

This way we can maintain as many project system as we see fit, without having
to manually maintain them when we add or remove new code to the repository.
Only the structure of the project file is relevant to the template. The actual
list of source code and targets isn't.

# Structure of `build.yaml`

The `build.yaml` file has the following structure:

```
settings:  # global settings, such as version number
  ...
filegroups:  # groups of files that are automatically expanded
  ...
libs:  # list of libraries to build
  ...
target:   # list of targets to build
  ...<commit_msg>Fixed typo in templates documentation<commit_after># Regenerating project files

Prerequisites
- `python`
- `pip install mako` (the template processor)
- `pip install pyyaml` (to read the yaml files)
- `go` (required by boringssl dependency)

```
# Regenerate the projects files (and other generated files) using templates
tools/buildgen/generate_projects.sh
```

# Quick justification

We've approached the problem of the build system from a lot of different
angles. The main issue was that there isn't a single build system that
was going to single handedly cover all of our usage cases.

So instead we decided to work the following way:

* A `build.yaml` file at the root is the source of truth for listing all the
targets and files needed to build grpc and its tests, as well as a basic system
for dependency description.

* Most of the build systems supported by gRPC (e.g. Makefile, cmake, XCode) have a template defined in this directory. The templates use the information from the `build.yaml` file to generate the project files specific to a given build system.

This way we can maintain as many project system as we see fit, without having
to manually maintain them when we add or remove new code to the repository.
Only the structure of the project file is relevant to the template. The actual
list of source code and targets isn't.

# Structure of `build.yaml`

The `build.yaml` file has the following structure:

```
settings:  # global settings, such as version number
  ...
filegroups:  # groups of files that are automatically expanded
  ...
libs:  # list of libraries to build
  ...
targets:   # list of targets to build
  ...
{'fraction_non_alphanumeric': 0.058264336093222936, 'fraction_numerical': 0.0, 'mean_word_length': 4.057364341085271, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3264075', 'n_tokens_mistral': 853, 'n_tokens_neox': 823, 'n_words': 492}