summaryrefslogtreecommitdiffstats
path: root/scripts/devtool
Commit message (Collapse)AuthorAgeFilesLines
* meta/lib+scripts: Convert to SPDX license headersRichard Purdie2019-05-091-11/+1
| | | | | | | | | | | | | | | | | | | | | | | This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Use ConfigParser instead of SafeConfigParserKhem Raj2018-08-141-1/+1
| | | | | | | | | | | | | | | The SafeConfigParser class has been renamed to ConfigParser in Python 3.2+ see http://bugs.python.org/issue10627 This alias will be removed in future versions.So we can use ConfigParser directly instead. (From OE-Core rev: 3c05c8fff779bd190b31fa8aa16b7a1b24420a60) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool/oeqa: Ensure added layers set LAYERSERIES_COMPATRichard Purdie2018-04-071-0/+1
| | | | | | | | | | Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated code from devtool/oeqa needs to set this to avoid warnings which break various tests. (From OE-Core rev: 27568410ebb0d40db3428550704f35199df0e034) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: fix poor handling of upgraded BBCLASSEXTENDed recipesPaul Eggleton2018-03-011-2/+3
| | | | | | | | | | | | | | | Fix two aspects of handling BBCLASSEXTENDed targets (e.g. openssl-native) that have been run through "devtool upgrade": * Fix recipe name not showing up in "devtool status" * Fix "devtool reset" not deleting empty directories under the recipe directory within the workspace, which may lead to problems if you subsequently run "devtool upgrade" on the same target again (From OE-Core rev: 56e04260d64de9c5b83893d97cf41b7ea9a45878) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: stop always moving workspace to end of BBLAYERSPaul Eggleton2017-11-111-1/+5
| | | | | | | | | | | | | | | | | | | | I noticed that using bitbake-layers add-layer followed by a devtool command resulted in bitbake re-parsing all of the recipes, which is annoying. Upon closer inspection I could see that devtool was moving the workspace layer path to the end of BBLAYERS if it happened to be somewhere in the middle - there's no need for it to be doing this. This occurred because we were passing the current workspace path to remove and the "new" path to add even if the path is not being changed, and I think earlier versions of bb.utils.edit_bblayers_conf() didn't move the existing entry under these circumstances as it clearly does now. Fix it so we only pass the path to be removed if we're actually changing the path. (From OE-Core rev: 284426dbad91a3c52eaf7da5c58fe8a2c2dfb826) 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: fix handling of oe-local-files when source is in a subdirectoryPaul Eggleton2017-11-111-4/+11
| | | | | | | | | | | | | | | | | | If S points to a subdirectory of the source rather than the "base" of the source tree then we weren't handling the oe-local-files directory properly - it got extracted to the base of the tree but devtool update-recipe and devtool finish assumed it would be under S which would be the subdirectory, thus it would be missing and devtool would assume the files had been deleted and remove them from the recipe. Record the base of the source tree in the bbappend and read it into the in-memory workspace so we can use that to find out where oe-local-files should be found. (From OE-Core rev: 30d2ea67b2c4727e23d06a35745b1afa64b130cc) 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: ensure recipes devtool is working on are unlocked within the eSDKPaul Eggleton2017-09-181-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Alongside reworking the way devtool extracts source, we now need to ensure that within the extensible SDK where task signatures are locked, the signatures of the tasks for the recipes being worked on get unlocked at the right time or otherwise we'll now get taskhash mismatches when running devtool modify on a recipe that was included in the eSDK such as the kernel (due to a separate bug). The existing mechanism for auto-unlocking recipes was a little weak and was happening too late, so I've reimplemented it so that: (a) it gets triggered immediately when the recipe/append is created (b) we avoid writing to the unlocked signatures file unnecessarily (since it's a global configuration file) and (c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES to avoid unnecessary reparses every time we perform one of the devtool operations that does need to change this list. Fixes [YOCTO #11883] (not the underlying cause, but this manifestation of the issue). (From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: check locale and refuse to start if it isn't UTF-8Paul Eggleton2017-01-231-0/+3
| | | | | | | | | | | | | | | | | We need to ensure the locale is UTF-8 or otherwise strange errors will occur later on during execution - the same reason we check this in BitBake itself. Unfortunately this check has to be before command line parsing and therefore showing the help text in response to --help, since that relies upon parsing bitbake's configuration (as we need to load plugins in other layers). Fixes [YOCTO #10908]. (From OE-Core rev: 370c6ba16c72bb52e80da098a5812ed1e09ac659) 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: remove True option to getVar callsJoshua Lock2016-12-161-1/+1
| | | | | | | | | | | | | 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\) (From OE-Core rev: 0a36bd96e6b29fd99a296efc358ca3e9fb5af735) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: prevent BBHandledException from showing tracebackPaul Eggleton2016-12-141-4/+7
| | | | | | | | | | | | If we don't catch this then attempting to run devtool in non-memres mode when bitbake is already running will produce a traceback instead of just an error message. (From OE-Core rev: e01b75dff599ffa2b66e6608b28bbb3564365eee) 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: Load plugins in a well defined orderOla x Nilsson2016-12-131-1/+2
| | | | | | | | | | | | | | | To allow devtool plugins in one layer to shadow another in a well defined way, first search BBPATH/lib/devtool directories and then scripts/lib/devool and load only the first found. The previous search and load loop would load all found plugins with the ones found later replacing any found before. (From OE-Core rev: 1b2b8a0a80de17ea053002fdd124055d2798029a) Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Add a line break to generated READMEJoe MacDonald2016-09-281-1/+1
| | | | | | | | | | | When devtool creates a new workspace, it produced a README with one very long line and no space following 'bblayers.conf'. Add a line break as was intended. (From OE-Core rev: 4ad1bcfc3c88ced5b7fc80c950613e31becb40f3) Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: ensure tinfoil is shut down correctlyPaul Eggleton2016-09-031-6/+4
| | | | | | | | | | | We should always shut down tinfoil when we're finished with it, either by explicitly calling the shutdown() method or by using it as a context manager ("with ..."). (From OE-Core rev: 5ec6d9ef309b841cdcbf1d14ac678d106d5d888a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: return specific exit code for incompatible recipesPaul Eggleton2016-07-121-1/+1
| | | | | | | | | | | | | 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. (From OE-Core rev: ffd295fed4ab81fc0bd00bb145ef4d72c49584bf) 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: ensure not specifying subcommand shows help textPaul Eggleton2016-06-151-0/+1
| | | | | | | | | | | | | | | | | | 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. (From OE-Core rev: d36fdea1a7f32d97187e0e9e6d701ae8fa304e8f) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: tweak README in created workspace layerPaul Eggleton2016-06-151-4/+7
| | | | | | | | | Clarify slightly the intended usage of the workspace layer. (From OE-Core rev: d9f3af6f4e6d3df30b411bbcc3c2b6f7f62c52ad) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: use python3 in shebangEd Bartosh2016-06-021-1/+1
| | | | | | | | | | | 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. (From OE-Core rev: dad9617809c60ec5f11d4780b0afa1cffa1efed5) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts: Rename ConfigParser -> configparser for python3Ed Bartosh2016-06-021-3/+3
| | | | | | | | | | | The ConfigParser API was renamed to configparser in python 3. Renamed ConfigParser -> configparser in scripts/ to make the code working in python 3. (From OE-Core rev: de6e98f272e623ce72e724e66920eecf10cb2d41) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Fix build-sdk when pn doesn't match filenameRandy Witt2016-05-111-0/+5
| | | | | | | | | | | | | | 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. (From OE-Core rev: d58a326b6960be14b8a049253559aec9582b7d0d) 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>
* devtool: Create unlocked-sigs.inc containing items in the workspaceRandy Witt2016-04-091-0/+20
| | | | | | | | | | | | | | | | | | | | | | 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] (From OE-Core rev: 6b2b5ffdcb8bf885a1c756ea132e9d2c55e13dcd) Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts, lib: Don't limit traceback lengths to arbitrary valuesRichard Purdie2016-03-311-1/+1
| | | | | | | | | | | | | | | | 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] (From OE-Core rev: 6069175e9bb97ace100bb5e99b6104d33163a3a2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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-05 18:48:16 +0000