aboutsummaryrefslogtreecommitdiffstats
path: root/lib/bblayers
AgeCommit message (Collapse)Author
2017-11-07bitbake-layers: Add support for multiple recipes at onceMark Hatle
bitbake-layers show-recipes and show-appends supported listing all recipes or one recipe. Adjust the system to permit specifying more then one recipe. Also update show-appends to match the --help description and support file style wildcards for selecting the recipe to display. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-10-06Add args.force to localargs before do_add_layerJeremy A. Puhlman
Adding layer "meta-signing-key" to conf/bblayers.conf Traceback (most recent call last): File "/local/build/project/build/poky/bitbake/bin/bitbake-layers", line 103, in <module> ret = main() File "/local/build/project/build/poky/bitbake/bin/bitbake-layers", line 96, in main return args.func(args) File "/local/build/project/build/poky/bitbake/lib/bblayers/layerindex.py", line 250, in do_layerindex_fetch self.do_add_layer(localargs) File "/local/build/project/build/poky/bitbake/lib/bblayers/action.py", line 44, in do_add_layer if not (args.force or notadded): AttributeError: 'Namespace' object has no attribute 'force' Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-05bitbake-layers: check layer dependencies before addingChang Rebecca Swee Fun
In the original implementation, "bitbake-layers add-layers <layer>" succeeded without error checking. This will further introduce failures in recipe parsing only when "bitbake" command is executed. Adding a meta layer without its dependency layer(s) should failed and exit the process gracefully. Added extra argument "-F" to force add a layer without checking layer dependency. [YOCTO #10913] Signed-off-by: Phoong Stanley Cheong Kwan <stanley.cheong.kwan.phoong@intel.com> Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-21bitbake-layers: fix layerindex-fetch for Python 3Paul Eggleton
The data we read from an HTTPConnection comes in the form of bytes, but we need it as a string, so in Python 3 we need to decode it (missed in the Python 3 migration). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-23bitbake-layers: show-appends: add optional argument to limit package listMatthew McClintock
Add ability to limit output per package: $ bitbake-layers show-appends m4 === Matched appended recipes === m4_1.4.17.bb: /home/mattsm/git/openembedded-core/meta-selftest/recipes-test/m4/m4_1.4.17.bbappend Useful for writing tools to process the output, and debugging bbappends for specific packages Signed-off-by: Matthew McClintock <msm-oss@mcclintock.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-14tinfoil: rewrite as a wrapper around the UIPaul Eggleton
Rewrite tinfoil as a wrapper around the UI, instead of the earlier approach of starting up just enough of cooker to do what we want. This has several advantages: * It now works when bitbake is memory-resident instead of failing with "ERROR: Only one copy of bitbake should be run against a build directory". * We can now connect an actual UI, thus you get things like the recipe parsing / cache loading progress bar and parse error handling for free * We can now handle events generated by the server if we wish to do so * We can potentially extend this to do more stuff, e.g. actually running build operations - this needs to be made more practical before we can use it though (since you effectively have to become the UI yourself for this at the moment.) The downside is that tinfoil no longer has direct access to cooker, the global datastore, or the cache. To mitigate this I have extended data_smart to provide remote access capability for the datastore, and created "fake" cooker and cooker.recipecache / cooker.collection adapter objects in order to avoid breaking too many tinfoil-using scripts that might be out there (we've never officially documented tinfoil or BitBake's internal code, but we can still make accommodations where practical). I've at least gone far enough to support all of the utilities that use tinfoil in OE-Core with some changes, but I know there are scripts such as Chris Larson's "bb" out there that do make other calls into BitBake code that I'm not currently providing access to through the adapters. Part of the fix for [YOCTO #5470]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-11-30bitbake: remove True option to getVar callsJoshua Lock
getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-17bitbake: Initial multi-config supportRichard Purdie
This patch adds the notion of supporting multiple configurations within a single build. To enable it, set a line in local.conf like: BBMULTICONFIG = "configA configB configC" This would tell bitbake that before it parses the base configuration, it should load conf/configA.conf and so on for each different configuration. These would contain lines like: MACHINE = "A" or other variables which can be set which can be built in the same build directory (or change TMPDIR not to conflict). One downside I've already discovered is that if we want to inherit this file right at the start of parsing, the only place you can put the configurations is in "cwd", since BBPATH isn't constructed until the layers are parsed and therefore using it as a preconf file isn't possible unless its located there. Execution of these targets takes the form "bitbake multiconfig:configA:core-image-minimal core-image-sato" so similar to our virtclass approach for native/nativesdk/multilib using BBCLASSEXTEND. Implementation wise, the implication is that instead of tasks being uniquely referenced with "recipename/fn:task" it now needs to be "configuration:recipename:task". We already started using "virtual" filenames for recipes when we implemented BBCLASSEXTEND and this patch adds a new prefix to these, "multiconfig:<configname>:" and hence avoid changes to a large part of the codebase thanks to this. databuilder has an internal array of data stores and uses the right one depending on the supplied virtual filename. That trick allows us to use the existing parsing code including the multithreading mostly unchanged as well as most of the cache code. For recipecache, we end up with a dict of these accessed by multiconfig (mc). taskdata and runqueue can only cope with one recipecache so for taskdata, we pass in each recipecache and have it compute the result and end up with an array of taskdatas. We can only have one runqueue so there extensive changes there. This initial implementation has some drawbacks: a) There are no inter-multi-configuration dependencies as yet b) There are no sstate optimisations. This means if the build uses the same object twice in say two different TMPDIRs, it will either load from an existing sstate cache at the start or build it twice. We can then in due course look at ways in which it would only build it once and then reuse it. This will likely need significant changes to the way sstate currently works to make that possible. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-17cache: Make virtualfn2realfn/realfn2virtual standalone functionsRichard Purdie
Needing to access these static methods through a class doesn't make sense. Move these to become module level standalone functions. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02bitbake-layers: show-layers: disable parsingPaul Eggleton
We don't need to parse all recipes just to show the list of layers, since that comes straight from the configuration, so save a bit of time by not doing so. (A minor regression that came in with the the bitbake-layers refactoring). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-01bitbake: Convert to python 3Richard Purdie
Various misc changes to convert bitbake to python3 which don't warrant separation into separate commits. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-05-17bitbake-layers: convert to plugin-basedChristopher Larson
This uses bb.utils.load_plugins, based on the plugin handling in recipetool and devtool in oe-core. Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>