summaryrefslogtreecommitdiff
path: root/scripts/devtool
AgeCommit message (Collapse)AuthorFiles
2016-07-12devtool: return specific exit code for incompatible recipesPaul Eggleton1
Certain recipes cannot be used with devtool extract / modify / upgrade - usually because they don't provide any source. Return a specific exit code (4) so that scripts such as scripts/contrib/devtool-stress.py know the difference between this and a genuine failure. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-06-14scripts: ensure not specifying subcommand shows help textPaul Eggleton1
With Python 2, argparse subparsers behaviour in Python 2 was to print the usage information if the subparsers argument wasn't specified. However, with Python 3.2.3 and later a subparsers argument is not required by default, leading to errors when no arguments are specified: AttributeError: 'Namespace' object has no attribute 'func' Restore the previous desired behaviour of showing the help text for devtool, recipetool and the devtool-stress script by setting subparsers.required to True. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-14devtool: tweak README in created workspace layerPaul Eggleton1
Clarify slightly the intended usage of the workspace layer. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-06-02scripts: use python3 in shebangEd Bartosh1
As most of oe-test cases work for devtool and recipetool it makes sense to switch both tools to python 3 by explicitly referring to python3 in their shebangs. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
2016-06-02scripts: Rename ConfigParser -> configparser for python3Ed Bartosh1
The ConfigParser API was renamed to configparser in python 3. Renamed ConfigParser -> configparser in scripts/ to make the code working in python 3. Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
2016-05-11devtool: Fix build-sdk when pn doesn't match filenameRandy Witt1
If an image with the filename foo.bb could be built using the name "bar" instead, then build-sdk would fail to create the derivative sdk. This was because the code assumed that the file name matched the target, which is not necessarily the case. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-08devtool: Create unlocked-sigs.inc containing items in the workspaceRandy Witt1
When a recipe is added to the workspace, the signatures for the tasks will change. This means that bitbake must be told to allow the signatures to be different if they are in locked-sigs.inc. This is done by creating an unlocked-sigs.inc file which contains all the recipes in the workspace each time devtool reads the workspace. So not only will necessary things get added, previously added items will be removed by virtue of them no longer being in the workspace. This also makes sure that the extensible sdk picks up unlocked-sigs.inc as part of the configuration. [YOCTO #9195] Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-31scripts, lib: Don't limit traceback lengths to arbitrary valuesRichard Purdie1
There appears to have been a lot of copy and pasting of the code which prints tracebacks upon failure and limits the stack trace to 5 entries. This obscures the real error and is very confusing to the user it look me an age to work out why some tracebacks weren't useful. This patch removes the limit, making tracebacks much more useful for debugging. [YOCTO #9230] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-21devtool: categorise and order subcommands in help outputPaul Eggleton1
The listing of subcommands in the --help output for devtool was starting to get difficult to follow, with commands appearing in no particular order (due to some being in separate modules and the order of those modules being parsed). Logically grouping the subcommands as well as being able to exercise some control over the order of the subcommands and groups would help, if we do so without losing the dynamic nature of the list (i.e. that it comes from the plugins). Argparse provides no built-in way to handle this and really, really makes it a pain to add, but with some subclassing and hacking it's now possible, and can be extended by any plugin as desired. To put a subcommand into a group, all you need to do is specify a group= parameter in the call to subparsers.add_parser(). you can also specify an order= parameter to make the subcommand sort higher or lower in the list (higher order numbers appear first, so use negative numbers to force items to the end if that's what you want). To add a new group, use subparsers.add_subparser_group(), supplying the name, description and optionally an order number for the group itself (again, higher numbers appear first). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-21devtool: Don't recursively look for .devtoolbase in --basepathRandy Witt1
If the user specifies --basepath on the commandline, only the directory specified should be searched for .devtoolbase. Otherwise when --basepath is a child of the sdk directory, .devtoolbase will always be found and devtool will only show options meant to be used within an sdk. Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-11devtool: refactor code for getting local recipe filePaul Eggleton1
We're doing this in a couple of places, let's just find the recipe file if it exists within the workspace (which it will if it's been added through "devtool add") when we read in the workspace. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22devtool: modify: default source tree pathPaul Eggleton1
As per the changes to "devtool add", make the source tree path optional and use the default path if none is specified. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22devtool: add: allow specifying URL as positional argumentPaul Eggleton1
Having to specify -f is a little bit ugly when a URI is distinctive enough to recognise amongst the other positional parameters, so take it as an optional positional parameter. -f/--fetch is still supported, but deprecated. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-22scripts: print usage in argparse-using scripts when a command-line error occursPaul Eggleton1
For scripts that use Python's standard argparse module to parse command-line arguments, create a subclass which will show the usage the usage information when a command-line parsing error occurs. The most common case would be when the script is run with no arguments; at least then the user immediately gets to see what arguments they might need to pass instead of just an error message. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-01devtool: clarify help textPaul Eggleton1
* Make some minor clarifications to help text * Drop ArgumentDefaultsHelpFormatter and just put the defaults in the text itself where needed (because otherwise you get defaults shown for store_true options which is somewhat confusing). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-01devtool: build: enable showing default task in helpPaul Eggleton1
Enable access to the configuration object in register_commands() so that we can read configuration values there; this allows us to show the task that will be run in the command line help for the build subcommand. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-12-01devtool: disable creating workspace for extract and search subcommandsPaul Eggleton1
For subcommands that don't actually involve the workspace, don't auto-create the workspace. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-09-23devtool: second fix for running from a different directoryMarkus Lehtonen1
Do not change change current working directory permanently, but, only for the duration of tinfoil initialization instead. The previous fix caused very unintuitive behavior where using relative paths were solved with respect to the builddir instead of the current working directory. E.g. calling "devtool extract zlib ./zlib" would always create create srctree in ${TOPDIR}/zlib, independent of the users cwd. (From OE-Core rev: 4c7f159b0e17a0475a4a4e9dc4dd012e3d2e6a1f) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-09devtool: fix running from a different directoryPaul Eggleton1
Fixes the following error when running devtool from a directory other than the build directory (or the SDK base path when using within the extensible SDK): The BBPATH variable is not set and bitbake did not find a conf/bblayers.conf file in the expected location. Maybe you accidentally invoked bitbake from the wrong directory? Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-08-19devtool: fix handling of BBCLASSEXTENDed recipesPaul Eggleton1
If a recipe is BBCLASSEXTENDed (e.g. to -native), its PN value and the name of the bbappend will be different; we were assuming them to be the same when reading in the workspace, leading to us seeing the base recipe name everywhere afterwards. Also add a test so we ensure this doesn't regress in future. Fixes [YOCTO #8157]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-08-01devtool: add --bbpath argumentChristopher Larson1
Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-31devtool: use tinfoil shutdown methodPaul Eggleton1
Tinfoil now has its own shutdown method, use it instead of calling into cooker - not only is it the right thing to do from an API perspective, it also ensures proper lock handling. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-27devtool: also load plugins from BBPATHChristopher Larson1
This makes it easier to extend, as a layer can add its own sub-commands. Argument parsing is also separated into two steps, the same way it's done in recipetool, as we need access to the global command-line arguments early, before plugins are loaded, both for debugging arguments and for the bitbake path (we need to load the bitbake module to get tinfoil, which is now needed to load the plugins). Rather than constructing tinfoil once and passing it through into sub-commands for their use, we have to construct it for configuration metadata, use it, and then shut it down, as some sub-commands call out to recipetool, which needs its own tinfoil instance, and therefore needs to acquire the bitbake lock. If we're still holding the lock at that point, that's clearly a problem. [YOCTO #7625] Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-06-18devtool: use DevtoolError for error handlingMarkus Lehtonen1
Use DevtoolError exception more widely for handling error cases. This exception is now caught in the main script and raising it can be used to exit with an error. This hopefully simplifies error handling. The change also makes exit codes more consistent, always returning '1' when an error occurs. Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
2015-06-18devtool: remove some unused return valuesMarkus Lehtonen1
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
2015-05-15devtool: if workspace layer exists, still ensure it's in bblayers.confPaul Eggleton1
When we run devtool, if the workspace layer already exists but isn't in bblayers.conf (perhaps because it was previously created but subsequently removed from bblayers.conf by the user) then we should add it and notify the user, otherwise devtool operations won't work. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2015-04-27devtool: handle . in recipe namePaul Eggleton1
Names such as glib-2.0 are valid (and used) recipe names, so we need to support them. Fixes [YOCTO #7643]. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-07devtool: improve command-line helpPaul Eggleton1
Based on feedback from Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-12-21scripts/devtool: add development helper toolPaul Eggleton1
Provides an easy means to work on developing applications and system components with the build system. For example to "modify" the source for an existing recipe: $ devtool modify -x pango /home/projects/pango Parsing recipes..done. NOTE: Fetching pango... NOTE: Unpacking... NOTE: Patching... NOTE: Source tree extracted to /home/projects/pango NOTE: Recipe pango now set up to build from /home/paul/projects/pango The pango source is now extracted to /home/paul/projects/pango, managed in git, with each patch as a commit, and a bbappend is created in the workspace layer to use the source in /home/paul/projects/pango when building. Additionally, you can add a new piece of software: $ devtool add pv /home/projects/pv NOTE: Recipe /path/to/workspace/recipes/pv/pv.bb has been automatically created; further editing may be required to make it fully functional The latter uses recipetool to create a skeleton recipe and again sets up a bbappend to use the source in /home/projects/pv when building. Having done a "devtool modify", can also write any changes to the external git repository back as patches next to the recipe: $ devtool update-recipe mdadm Parsing recipes..done. NOTE: Removing patch mdadm-3.2.2_fix_for_x32.patch NOTE: Removing patch gcc-4.9.patch NOTE: Updating recipe mdadm_3.3.1.bb [YOCTO #6561] [YOCTO #6653] [YOCTO #6656] Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>