summaryrefslogtreecommitdiffstats
path: root/scripts/devtool
Commit message (Collapse)AuthorAgeFilesLines
* 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-16 08:33:48 +0000