summaryrefslogtreecommitdiffstats
path: root/scripts/devtool
Commit message (Collapse)AuthorAgeFilesLines
* devtool: categorise and order subcommands in help outputPaul Eggleton2016-02-211-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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). (From OE-Core rev: e1b9d31e6ea3c254ecfe940fe795af44761e0e69) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Don't recursively look for .devtoolbase in --basepathRandy Witt2016-02-211-12/+16
| | | | | | | | | | | | 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. (From OE-Core rev: 3bb07c61220b89384a76c745e33be37aad5095c0) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: refactor code for getting local recipe filePaul Eggleton2016-01-111-1/+11
| | | | | | | | | | | 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. (From OE-Core rev: 81cf5580993c99050e3f4d6d891bc67534721487) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: modify: default source tree pathPaul Eggleton2015-12-281-0/+4
| | | | | | | | | | As per the changes to "devtool add", make the source tree path optional and use the default path if none is specified. (From OE-Core rev: 83707d1334fb094fd1877bcfd07a83866601048a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: allow specifying URL as positional argumentPaul Eggleton2015-12-281-0/+2
| | | | | | | | | | | | 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. (From OE-Core rev: aedfc5a5db1c4b2b80a36147c9a13b31764d91dd) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: print usage in argparse-using scripts when a command-line error occursPaul Eggleton2015-12-281-3/+4
| | | | | | | | | | | | | | 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. (From OE-Core rev: d62fe7c9bc2df6a4464440a3cae0539074bf99aa) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: clarify help textPaul Eggleton2015-12-011-1/+1
| | | | | | | | | | | | | * 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). (From OE-Core rev: a90ffea30c4578fd6acda2c5945b816ad33b13f5) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: build: enable showing default task in helpPaul Eggleton2015-12-011-0/+1
| | | | | | | | | | | | 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. (From OE-Core rev: 142d006de3235a034839ef7bbe147c56fc7af04a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: disable creating workspace for extract and search subcommandsPaul Eggleton2015-12-011-2/+2
| | | | | | | | | | | For subcommands that don't actually involve the workspace, don't auto-create the workspace. (From OE-Core rev: 90cba7992bc1d227e242666cd486414bd4a45f7e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: second fix for running from a different directoryMarkus Lehtonen2015-09-241-4/+1
| | | | | | | | | | | | | | | | | | 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) (From OE-Core rev: 05060699e63cd25d089e83e9aa56c11d5baa8fd8) 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>
* devtool: fix running from a different directoryPaul Eggleton2015-09-091-0/+3
| | | | | | | | | | | | | | | 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? (From OE-Core rev: 1687ec04bfee327fe24fdfecb67db689835769f2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix handling of BBCLASSEXTENDed recipesPaul Eggleton2015-08-191-6/+6
| | | | | | | | | | | | | | | | | 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]. (From OE-Core rev: b63fca00c2e24ad0c8b8b3c492d93ee4372fa92d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add --bbpath argumentChristopher Larson2015-08-011-4/+11
| | | | | | | (From OE-Core rev: a459b230387b34479212d54edeb3abf2b6274196) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: use tinfoil shutdown methodPaul Eggleton2015-08-011-2/+1
| | | | | | | | | | | 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. (From OE-Core rev: c1f58caad4ff45efd213bf1412304a72903abe7e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: also load plugins from BBPATHChristopher Larson2015-07-271-21/+36
| | | | | | | | | | | | | | | | | | | | | | | | 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] (From OE-Core rev: f9bc3b27244a141ec7273445d3ea139a047e0ddf) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: use DevtoolError for error handlingMarkus Lehtonen2015-06-181-1/+7
| | | | | | | | | | | | | 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. (From OE-Core rev: 2e4f1dcade7ccb581c7a390c32163ea3deeac6d5) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: remove some unused return valuesMarkus Lehtonen2015-06-181-1/+1
| | | | | | | (From OE-Core rev: 30fd41bd06a61e9df47263d49119fb8e193cdf68) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: if workspace layer exists, still ensure it's in bblayers.confPaul Eggleton2015-05-161-14/+22
| | | | | | | | | | | | 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. (From OE-Core rev: 313b622a6c6613092ed18a2158e090521344f6c0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: handle . in recipe namePaul Eggleton2015-04-271-1/+1
| | | | | | | | | | | | Names such as glib-2.0 are valid (and used) recipe names, so we need to support them. Fixes [YOCTO #7643]. (From OE-Core rev: b9fd8d4d4dfae72de2e81e9b14de072e12cecdcf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: improve command-line helpPaul Eggleton2015-02-081-8/+10
| | | | | | | | | | Based on feedback from Scott Rifenbark <scott.m.rifenbark@intel.com> (From OE-Core rev: ec3378f3a7013e289daa0f5c52329488b861f99c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/devtool: add development helper toolPaul Eggleton2014-12-231-0/+255
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] (From OE-Core rev: 716d9b1f304a12bab61b15e3ce526977c055f074) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-15 10:08:23 +0000