scotty in a nutshell

scotty main purpose is to create a dynamic kas configuration.

We chose kas because it offers a reliable way to recreate a full bitbake setup with just the parts required for a bitbake build.

Besides that scotty offers additional commands to perform various tasks automatically, see Scotty commands for more details.

How does it work?

For scotty to create a self-containing kas configuration, based on the user selected MACHINE, DISTRO and feature settings, we are running in two stages

manifest stage

As a first steps scotty clones a selection of repositories that includes

• simplecore-manifest

• simplecore-bsp

• simplecore-distro

into a build sub-folder called .manifest.

In those clone directories scotty scans for scotty-config.yaml files.

Each of these files will describe a user selectable MACHINE or DISTRO or feature, plus it can reference one or more kas configuration snippets (usually stored in a sub-folder called snippets in the respective repository).

Once the user made its selection scotty merges the referenced snippets (plus a few more dynamically created settings) into a full self-containing kas configuration.

This full config can be found at build/.effective-config.yml.

Changes are detected by scotty

Changes to the overall configuration are detected by scotty automatically.

BUT scotty will not update any of the potentially existing .manifest clones on it’s own.

To update existing checkouts run scotty with

scotty --force-sync ...

build stage

From the previously generated full config, scotty now hands over to kas to create the build workspace in a sub-folder called build and sets up the bitbake configuration.

Changes are detected by scotty

Changes to the overall configuration are detected by scotty automatically.

BUT scotty will not update any of the potentially existing build clones on it’s own.

To update existing checkouts run scotty with

scotty --refresh ...