If we're creating a LayerBranch record, it's helpful to copy the
maintainer and dependency records in from master as they're usually
going to be the same; if they're not the user can always change them
afterwards.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
So it turns out that one or two layers have changed in structure between
branches, so we need to be able to specify this on a per-branch basis.
Good times...
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Don't assume the current directory contains our conf/local.conf,
explicitly use the directory above where the script is located.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Change the data structure to support multiple branches. At the top level
there is a set list of Branch objects, and then a LayerBranch object
between each layer and the maintainers, dependencies, recipes and
machines, so that the set of each can be different per branch. The
branch is a session option, and can be selected via a drop-down that is
shown for all pages.
Additionally, with this change we avoid the need to run the update
script within a build environment set up with oe-init-build-env - since
we need a specific version of BitBake per branch we now use our own copy
of BitBake which is fetched by the script itself. The update script will
need to be called multiple times however - once per branch.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If there is more than one layer in a repository, we want the latest
commit in the subdirectory not the entire repository (since we use it
to determine the last commit date which should show how "fresh" the
layer is).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
If we aren't doing a full refresh, when changes to an included/required
file or an inherited class occur we need to update all of the files that
depend on them. BitBake records these dependencies, so read them and
record them against each recipe.
At the moment this only handles dependencies within the same layer; that
is probably sufficient to handle most changes for the purposes of
extracting the data this application cares about. A future improved
solution will probably involve making use of BitBake's cache rather than
and parsing all layers and their dependencies rather than individual
recipes.
This change also adds -x/--nofetch and -n/--dry-run options for
debugging as well as some further debug messages.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
"Fatal" errors during parsing a single recipe (such as finding legacy
staging) shouldn't stop us from parsing the rest of the layer. To do
this we need to catch BaseException instead of Exception as fatal errors
end up calling sys.exit.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Parse layer.conf files so that BBPATH is set correctly as well as any
other custom variables. This required the repository fetching to be
split out of the update process and done first so that we're sure we
have the data for the other layers.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Look for conf/machine/*.conf and add a record for each file found. These
are displayed in the layer detail page if any are present.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Set BBPATH so that files from the layer can be found when recipes use
include/require pointing to files with a specific path, or use
inherit to inherit a class in the layer.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
meta-ti has a recipe in it that causes parsing to fail with a fatal
error due to LICENSE not being set; for the purposes of the layer index
just set a default value for LICENSE so that this doesn't break parsing.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
By default, if DESCRIPTION is not set it takes the value of SUMMARY.
However, within this tool it is useful for us to be able to tell when
DESCRIPTION has not been set so we want it to be blank if that is the
case.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
The default value of HOMEPAGE ('unknown', set from bitbake.conf) is not
particularly helpful - we want it to be blank if it's not set, so just
set it to blank before parsing each recipe.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
