path: root/scripts/lib/devtool/package.py
Commit message (Collapse)AuthorAgeFilesLines
* devtool: categorise and order subcommands in help outputPaul Eggleton2016-02-211-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* devtool: drop unused plugin_init() functionsPaul Eggleton2015-12-011-4/+0
| | | | | | | | This function is no longer required to be defined for a plugin, so drop it where it's a no-op. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* devtool: package: use DEPLOY_DIR_<pkgtype> to get deploy directoryPaul Eggleton2015-12-011-8/+12
| | | | | | | | Rather than reconstructing the output path for packages, use the proper variable. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* devtool: second fix for running from a different directoryMarkus Lehtonen2015-09-231-1/+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) 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: check that source tree still existsPaul Eggleton2015-09-221-4/+2
| | | | | | | | | | | | Sometimes, particularly if you extracted the source to /tmp which is on tmpfs, the external source tree that is being pointed to may no longer exist when you come to run "devtool build" or "devtool update-recipe" etc. Make all of the commands that need to check for a recipe being in the workspace call a single function and have that function additionally check the source tree still exists where appropriate. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add package plugin that lets you create package via devtoolBrendan Le Foll2015-09-091-0/+61
Enables creating packages using devtool within the extensible SDK. (This is only enabled within the extensible SDK because it provides no advantage over just running bitbake directly there). Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>