<commit_before># Jagen

Jagen eases the development of multiple interdependent software packages by
generating a meta project which abstracts the peculiarities of their respective
build and source control systems and provides instruments to uniformly manage
them as a whole.

It mainly targets embedded development use cases when things should be done
"your way" instead of shoving the requirements into rigid paradigms of Yocto
and Buildroot. In particular, integrating third-party SDKs, pre-built
toolchains or packages with non-standard build systems intended to be a
straightforward process. The focus is on ease of use and adoption rather than
trying to provide yet another idiosyncratic collection of recipes for every
possible piece of software. On the other hand, vendor and project-specific
recipe libraries and patches are well-supported and adding packages using
mainstream build systems (such as Autotools and CMake) is trivial.

The generated build system is simple to understand and customize. It collects
all commands outputs and allows to selectively repeat any stage (such as
configure or compile) of a single or multiple packages respecting the
dependencies and running to completion of a certain target such as creation of
a filesystem image. It is possible to combine multiple projects or parts into a
single product using the concept of "layers".

The built-in workspace management facilities allow SCM-controlled (Git and
Mercurial) packages to be inspected, updated, cleaned up, etc. using universal
commands. They replicate the most common use cases of Google's Repo and gclient
tools such as cloning and updating of multiple repositories. The sources in the
form of distribution archives are also supported. They will be automatically
downloaded and verified during the build. The source repositories and archives
are cached and can be shared between different projects.

Jagen is a mature project which is used in production since 2014.

## Requirements

POSIX compatible shell, Lua 5.1 or 5.2 (or LuaJIT 2.0), [Ninja](https://ninja-build.org/).

## Getting Started

To start using Jagen execute the following commands:

```
mkdir -p ~/root-genivi && cd ~/root-genivi
curl -fsSL https://raw.githubusercontent.com/bazurbat/jagen/master/jagen-init | sh -s -- genivi -a ccache
. ./env.sh
jagen build
```

1. Create work directory and go into it.
2. Clone Jagen and initialize the project.
3. Source the generated `env.sh`.
4. Build the project.

The `curl` command fetches a `jagen-init` script which clones Jagen to the
`.jagen` subdirectory and runs `init-project` from it with the supplied
arguments. The name "genivi" is one of the project templates distributed with
Jagen. The "-a" option enables the "ccache". Source the `env.sh` again when you
want to resume working with the project. The `build` command runs to
completion, i.e. it ensures that all default targets are built, if it is
already the case, similarly to "make", it does nothing.

See [Initializing](doc/Initializing.md) section in the manual for more details.

During the build the source repositories will be cloned to the `src` directory,
the distribution archives will be downloaded to the `dist` directory. Inspect
what is currently checked out with the `jagen src status` command.

You can find working directories along with build output files for each package<commit_msg>Use the shortened URL for the jagen-init<commit_after># Jagen

Jagen eases the development of multiple interdependent software packages by
generating a meta project which abstracts the peculiarities of their respective
build and source control systems and provides instruments to uniformly manage
them as a whole.

It mainly targets embedded development use cases when things should be done
"your way" instead of shoving the requirements into rigid paradigms of Yocto
and Buildroot. In particular, integrating third-party SDKs, pre-built
toolchains or packages with non-standard build systems intended to be a
straightforward process. The focus is on ease of use and adoption rather than
trying to provide yet another idiosyncratic collection of recipes for every
possible piece of software. On the other hand, vendor and project-specific
recipe libraries and patches are well-supported and adding packages using
mainstream build systems (such as Autotools and CMake) is trivial.

The generated build system is simple to understand and customize. It collects
all commands outputs and allows to selectively repeat any stage (such as
configure or compile) of a single or multiple packages respecting the
dependencies and running to completion of a certain target such as creation of
a filesystem image. It is possible to combine multiple projects or parts into a
single product using the concept of "layers".

The built-in workspace management facilities allow SCM-controlled (Git and
Mercurial) packages to be inspected, updated, cleaned up, etc. using universal
commands. They replicate the most common use cases of Google's Repo and gclient
tools such as cloning and updating of multiple repositories. The sources in the
form of distribution archives are also supported. They will be automatically
downloaded and verified during the build. The source repositories and archives
are cached and can be shared between different projects.

Jagen is a mature project which is used in production since 2014.

## Requirements

POSIX compatible shell, Lua 5.1 or 5.2 (or LuaJIT 2.0), [Ninja](https://ninja-build.org/).

## Getting Started

To start using Jagen execute the following commands:

```
mkdir -p ~/root-genivi && cd ~/root-genivi
curl -fsSL https://git.io/vADit | sh -s -- genivi -a ccache
. ./env.sh
jagen build
```

1. Create work directory and go into it.
2. Clone Jagen and initialize the project.
3. Source the generated `env.sh`.
4. Build the project.

The `curl` command fetches a `jagen-init` script which clones Jagen to the
`.jagen` subdirectory and runs `init-project` from it with the supplied
arguments. The name "genivi" is one of the project templates distributed with
Jagen. The "-a" option enables the "ccache". Source the `env.sh` again when you
want to resume working with the project. The `build` command runs to
completion, i.e. it ensures that all default targets are built, if it is
already the case, similarly to "make", it does nothing.

See [Initializing](doc/Initializing.md) section in the manual for more details.

During the build the source repositories will be cloned to the `src` directory,
the distribution archives will be downloaded to the `dist` directory. Inspect
what is currently checked out with the `jagen src status` command.

You can find working directories along with build output files for each package
{'fraction_non_alphanumeric': 0.04819277108433735, 'fraction_numerical': 0.004164807377658783, 'mean_word_length': 4.626778242677824, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 4, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1230860', 'n_tokens_mistral': 1716, 'n_tokens_neox': 1615, 'n_words': 993}