This chapter describes how to setup a new OE-lite project, ie. the creation of a new OE-lite manifest and setup of an OE-lite repository for it.
Convert layers to be of internal layer type.
The bakery.conf follows the OE-lite metadata syntax, or rather a subset of it. The primary purpose is to assign a value to the variable called OESTACK, which defines the OE-lite stack .
An OE-lite stack is composed of a number of OE-lite layers, with each layer typically being a seperate git repository.
The resulting OESTACK variable is thus a space separated list of layers. Each layer is specified by a path and a number of parameters, separated by ”;”.
and all the layers should be cloned from their upstream origin.
You are now (almost) ready to build something. To try this, see chapter Building for how to build.
With this, users of your manifest will get an OE-lite/core layer at meta/core, using a clone from the git://oe-lite.org/oe-lite/core.git repository.
While this is definitely a lean and simple approach, it does come with a few drawbacks.
You will not be able to create any commits, tags or branches to the OE-lite/core layer.
When cloning the OE-lite repository, you depend on both the server hosting the manifest repository and the oe-lite.org server.
See also appendix OE-lite Terminology for definition of internal layer.
For each layer you have added to the OE-lite stack as an external layer, you should consider to convert it to be an internal layer to address the problems with external layers described above. See appendix OE-lite Terminology for definition of internal layer.
When creating a clone of the OE-lite repository, you will only have to fetch from your project OE-lite repository.
You will be able to create backup/redundant copies of your entire OE-lite repository using a single command.
You will be able to switch back and forth between different copies of your OE-lite repository without making any changes to the OE-lite manifest.
You will be able to make complete from local clones of your OE-lite repository, without depending on any remote repositories.
Change the url entry of the layer submodule in .gitmodules to the path relative to the containing git super project. Fx. the relative path of meta/core contained in the manifest repository is ./meta/core, and the relative path of lib/GitPython/git/ext/async contained in the lib/GitPython submodule is ./git/ext/async .
When done, run oe update and commit the changes in conf/bakery.conf and .gitmodules files.
This section describes how to setup an OE-lite repository, suitable for hosting as a remote repository. Details on how to setup hosting is out of scope of this section.
OE-lite Bakery version 4.1 or newer is required for this.
This will create a new (bare) OE-lite repository clone of <url> at the local directory <path>. The <url> argument can be any valid git URL (see link:See git[git clone documentation] for more on this). This even includes a local path to an OE-lite manifest repository, which is handy for setting up the first OE-lite repository right after creation of a new OE-lite manifest.
All internal layers will be cloned (recursively) together with the manifest repository. Any other git submodules (ie. git submodules with absolute url’s or relative paths different from the path relative to the git super project) will not be cloned.