summaryrefslogtreecommitdiffstats
path: root/scripts/lib/devtool
Commit message (Collapse)AuthorAgeFilesLines
* devtool: add build-sdk subcommandPaul Eggleton2016-03-072-22/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a build-sdk command which is only available within the extensible SDK that builds a derivative extensible SDK. The idea is recipes in the workspace become a part of the new SDK - for example, this allows taking a vendor provided SDK, adding a few libs and then producing a new SDK with those included. When normally building the extensible SDK, the workspace is excluded; here we need to copy into the new SDK (renaming it in the process); the recipes' task signatures become locked and thus the sources are no longer needed, so they are removed along with the workspace bbappends which would interfere with the locked signatures. Additionally we need to just copy the configuration files (i.e. local.conf and auto.conf) rather than filtering and appending to them since that work has already been done when constructing the original SDK. The extra sstate artifacts from workspace recipes are also determined and copied into the new SDK in minimal mode (on the assumption that you won't set up a new sstate mirror). This reuses some code from build-image, so that needed to be generalised to allow that. Implements [YOCTO #8892]. (From OE-Core rev: 59e207ff6dd4b50a8905e14bc9292cf2794f4e7a) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: build-image: rename modulePaul Eggleton2016-03-071-0/+0
| | | | | | | | | | Hyphens aren't allowed in python identifiers, so you shouldn't use them in module names or they are more difficult to import. (From OE-Core rev: e8f6db9436dfc923e236f2cbc08f357e3b24fd5d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sdk.py: Fix undefined variableJuro Bystricky2016-03-031-0/+1
| | | | | | | | | | | | | | | | | | | | "sdk_update" uses a variable newsdk_path, which was never declared. This would cause the command: devtool sdk-update <poky-sdk-latest> to fail with an error: NameError: global name 'newsdk_path' is not defined The remedy is to declare newsdk_path as it was no doubt intended, corresponding to the argument specifying <poky-sdk-latest>. [YOCTO#9042] (From OE-Core rev: 6ac589a4a9290665f8c5295e2e2a03a2b187b957) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: upgrade: print new recipe namePaul Eggleton2016-02-281-0/+1
| | | | | | | | | | | Make this consistent with "devtool add" so that the user knows where to find the new recipe. (From OE-Core rev: 28fea4a104ba85aded2ecfe891e9bf997d72a103) 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: upgrade: drop PR on upgradePaul Eggleton2016-02-281-3/+4
| | | | | | | | | | | The PR value should be reset to the default when upgrading, so we need to drop it from the newly created file. (From OE-Core rev: 4acf8a6912106dd3da5ceee9e30ccce86211d04b) 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: upgrade: eliminate unnecessary datastore copyPaul Eggleton2016-02-281-4/+3
| | | | | | | | | | | We aren't modifying the datastore copy here, so we don't need a copy at all. (From OE-Core rev: 9f05bf98d4dbcb991b684a2ab480c6638c6be292) 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: upgrade: fix several issues with extraction of new sourcePaul Eggleton2016-02-281-2/+12
| | | | | | | | | | | | | | | | | Fix several issues when extracting the new version source over the top of the old one (when the recipe is not fetching from a git repo): * Delete the old source first so we ensure files deleted in the new version are deleted. This also has the side-effect of fixing any issues where files aren't marked writeable in the old source and thus overwriting them failed (harfbuzz 1.1.3 contains such files). * Fix incorrect variable name in abspath statement that made it a no-op (From OE-Core rev: 4f7595a514661f0e2418393286849a1cb6c46f0d) 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: upgrade: fix constructing new branch from tarball releasesPaul Eggleton2016-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | When we do an upgrade from one tarball version to another we want to: 1) Check out the old version as a new branch 2) Record the changes between the old and new versions as a commit 3) Check out the old version with patches applied 4) Rebase that onto the new branch Where we went wrong was step #1 where instead we checked out the old version with patches applied as the new branch, which meant the rebase didn't do anything and any changes made by the patches to files still in the new version were wiped out. (From OE-Core rev: a4f3e6d5f4c549e36cce1e18801a565a3a3c9b0a) 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: upgrade: fix renaming of recipe if PV is not in namePaul Eggleton2016-02-281-11/+11
| | | | | | | | | | | | | If the actual value of PV isn't in the name of the recipe (for example, a git or svn recipe) there's no point trying to rename it. Additionally, we already have the original filename, there's no need to guess it - just pass it in. (From OE-Core rev: e144db3650b4a7c0a59066621905f34a5400303e) 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: upgrade: fix moving version-specific files directoryPaul Eggleton2016-02-281-1/+1
| | | | | | | | | | | We were trying to move this from the current directory instead of the path. Let's just use shutil.move() instead of shelling out to mv. (From OE-Core rev: 60454a0ba154d6c777e0c2b05b887b4e4fcde986) 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: upgrade: fix version argument checkingPaul Eggleton2016-02-281-2/+7
| | | | | | | | | | | | | | | | For recipes that specify SRCREV, the code here wasn't quite doing the right thing. If the recipe has a SRCREV then that needs changing on upgrade, so ensure that the user specifies it. If it doesn't, then it'll be "INVALID" not None since the former is the actual default, so handle that properly as well. Additionally an unset variable was being erroneously passed when raising the error about the version being the same leading to a traceback, so fix that as well. (From OE-Core rev: 1d0f821371d1cb93e30fad86f0c20e38cb93b54b) 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: upgrade: drop superfluous call to validate_pnPaul Eggleton2016-02-281-5/+0
| | | | | | | | | | | | | The recipename argument to devtool upgrade specifies an existing recipe, so by definition the name will be valid (or it won't exist) - we don't need to validate it ourselves, that's only needed for situations like in devtool add where we're creating a new recipe. (From OE-Core rev: 1e2bc7d861555a04350a87f19047efdc717046be) 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: upgrade: make source tree path optionalPaul Eggleton2016-02-281-7/+15
| | | | | | | | | | | | Make devtool upgrade consistent with devtool add/modify in defaulting to sources/<recipename> under the workspace if no source tree path is specified. (From OE-Core rev: 8a952407b192313515e91570632446b6dff01665) 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: modify: fix source tree default name when mapping virtualsPaul Eggleton2016-02-281-17/+18
| | | | | | | | | | | | | | If you for example ran devtool modify virtual/libusb0 without specifying a source tree path, the default was <workspace>/sources/virtual/libusb0 which isn't correct - it should be using the mapped name i.e. libusb-compat (in the default OE-Core configuration). Reorder some of the code to ensure that the mapped name is used. (From OE-Core rev: c51736df17da8e6e561dd5b7ce59cb08254da870) 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: tweak auto-determining name failure messagePaul Eggleton2016-02-281-1/+1
| | | | | | | | | | As suggested by Khem Raj. (From OE-Core rev: 36cc6b81d0281348a0f241a80ddd427745a6a678) 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: update-recipe: create config fragmentMarkus Lehtonen2016-02-281-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | Create config fragment if the user makes modifications to kernel config. User may change .config e.g. by directly editing it or by running the 'do_menuconfig' bitbake task. Devtool generates one monolithic fragment by simply doing a diff between .config and .config.baseline files in the source directory. If either of these files is missing, the config fragment is not gerenrated or updated. The output is a file, 'devtool-fragment.cfg' that gets added to SRC_URI in the recipe (as well as copied into the 'oe-local-files' directory if that is present in the source tree). ${S}/.config will be a symlink to ${B}/.config. We need to do this as devtool is not able to access ${B} because ${B} is set in a .bbappend in the workspace layer which is not parsed by devtool itself. [YOCTO #8999] (From OE-Core rev: 524da136e5b837a60682516ac08f3092c635e934) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sync: update kernel configMarkus Lehtonen2016-02-281-1/+5
| | | | | | | | | | | Copy kernel config is copied to the source directory at a later phase in _extract_source() so that it gets copied when devtool sync is done, too. (From OE-Core rev: ff895be7a46c4b3b1b791e5387490d90bb34fce2) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: modify: tweak help description for behaviour changePaul Eggleton2016-02-211-2/+2
| | | | | | | | | | I should have adjusted this in OE-Core commit 80a44e52609a89d9ffe816181ae193af491c06ac where the behaviour changed. (From OE-Core rev: 13409a2b899bb74b8060c840b8c7ef8759d099cb) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: preserve existing filesPaul Eggleton2016-02-211-9/+78
| | | | | | | | | | | | | | | | If files would be overwritten by the deployment, preserve them in a separate location on the target so that they can be restored if you later run devtool undeploy-target. At the same time, also check for sufficient space before starting the operation so that we avoid potentially failing part way through. Fixes [YOCTO #8978]. (From OE-Core rev: a2da55712691bcf1066c53d813107d75213d6b10) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: undeploy-target: support undeploying all recipesPaul Eggleton2016-02-211-20/+39
| | | | | | | | | | | | | | | | | | | | | If you want to put the target device back to exactly how it was before devtool deploy-target started poking things into it, then it would make things easier if you didn't have to figure out which recipes were deployed. Now that we have the list stored on the target we can determine this reliably, so add a -a/--all option to undeploy-target to undeploy everything that has been deployed. One of the side-effects of this is that the dry-run functionality for undeploy-target had to be reimplemented to actually run the script on the target, since we have no way of knowing what's been deployed from the host side. We don't need to do the same for deploy-target though since we know exactly which files will be deployed without referring to the target. (From OE-Core rev: 41fed83060f0041e14e455d1446397bda277d953) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: deploy-target: write deployed files list to targetPaul Eggleton2016-02-211-41/+103
| | | | | | | | | | | | | | | | | | | | | When running devtool deploy-target, we save a list of deployed files, and this list is used by devtool undeploy-target (or the next time deploy-target is run if the list is present, in case any files have been renamed or deleted since the first time). We were writing this file to the host, but it makes more sense to write the list to the target instead, so that if we for example swap in a different board, or switch hosts, things will work as expected. In order to do this properly we have to construct a shell script and ship it over to the target so we can run it. The manifest is written out to a hidden directory in the root (/.devtool). Fixes [YOCTO #7908]. (From OE-Core rev: a16a0c9334b785e2df896266c8911a2c7a1806b8) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sdk-update: tweak command-line handling of updateserverPaul Eggleton2016-02-211-4/+7
| | | | | | | | | | | | Get the default value for updateserver from the configuration file and show it in the help; also only make the parameter optional if it's specified. This means we can also drop the check in the function as argparse will then ensure it's specified if there's no config setting. (From OE-Core rev: 82497bde58fc8bdae8d8acfbf025a1a90b14cc3e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: (un)deploy-target: add help descriptionsPaul Eggleton2016-02-211-0/+2
| | | | | | | | | Add a long description used when running --help on the specific command. (From OE-Core rev: eb7787d1652fd84a149fd394969f4f1099406051) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: categorise and order subcommands in help outputPaul Eggleton2016-02-2110-19/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: update-recipe: don't show workspace recipe warning if no updatePaul Eggleton2016-02-211-5/+9
| | | | | | | | | | If we didn't make any changes to the file then there's no point warning the user that we have done. (From OE-Core rev: 391b9ba30d802ac420ddf382588e03e718861c01) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: reset: fix preserving patches/other files next to recipesPaul Eggleton2016-02-211-4/+4
| | | | | | | | | | | | | | | | If files had been created next to the recipe (for example devtool add, edit the source and commit and then devtool update-recipe), running devtool reset failed to preserve those files and gave an error due to trying to rmdir the directory containing them which wasn't empty. Fix the preservation of files in the "attic" directory properly so we catch anything under the directory for the recipe, and replicate the same structure in the attic directory rather than slightly flattening it as we were before. (From OE-Core rev: bbe63eb97ae7f78959f117d6066ef821c4da1c77) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool / recipetool: use common code for launching editorPaul Eggleton2016-02-211-11/+2
| | | | | | | | | | | | | | | Looking at Chris Larson's code for starting the user's editor for "recipetool newappend" it was slightly better than what I wrote for "devtool edit-recipe" in that it checks VISUAL as well as EDITOR and defaults to vi if neither are set, so break this out to its own function and call it from both places. The broken out version passes shell=True however in case it's a more complicated command rather than just a name of an executable. (From OE-Core rev: 184a256931e8cdc7bea97a905c4e67a435964de0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: minor fix for error messagePaul Eggleton2016-02-211-1/+1
| | | | | | | | | | There is no -N/--name option for devtool, that's a recipetool option - with devtool you just specify the name as a positional argument. (From OE-Core rev: d2bc0cba5ca8a7220ffe1ef96acf856fe972ce7c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: fix adding from a local source directoryPaul Eggleton2016-02-111-1/+1
| | | | | | | | | | | | | Fix a regression introduced in in OE-Core revision aedfc5a5db1c4b2b80a36147c9a13b31764d91dd where specifying a local source tree without specifying a name resulted in a traceback. Fixes [YOCTO #9086]. (From OE-Core rev: 67ea9d21f20a371a0ee443b46326018cb1527b62) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: modify: make -x the default behaviourPaul Eggleton2016-02-111-6/+8
| | | | | | | | | | | | | | | It's going to be more common for users not to have the prepared source tree for a recipe already, so the default behaviour ought to be to extract it for them from the recipe. Change the default to extract (effectively making the -x option a no-op) and add a --no-extract/-n option to disable it. Later we can look at trying to be smart and reusing an existing source tree instead of erroring out if it exists; for now this is just the default reversal. (From OE-Core rev: 80a44e52609a89d9ffe816181ae193af491c06ac) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: commit for extra tasks that modify source when extractingPaul Eggleton2016-02-111-13/+35
| | | | | | | | | | | | | | | | When extracting source for a recipe, if there are additional custom tasks run that make changes to the source, create a commit in the generated git branch so they are contained. This is particularly useful for tasks that come before do_patch since otherwise the changes might get incorporated in the first applied patch, but otherwise it helps avoid the tree being dirty at any point. Fixes [YOCTO #7626]. (From OE-Core rev: 997a77d9b20af1778b804778e5d8c8a7424f7582) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* scripts/devtool: Add getVarFlag expand argumentRichard Purdie2016-02-061-1/+1
| | | | | | (From OE-Core rev: afa9b1081848cf0dbc40bbaf565bcc2ee19e8f6e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: extract: use the correct datastore for builddirMarkus Lehtonen2016-01-261-1/+1
| | | | | | | | (From OE-Core rev: 6f5bec4570a9237681fcee3922209af2a48f6c07) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add configure-help subcommandPaul Eggleton2016-01-262-4/+175
| | | | | | | | | | | | | | | | | | | | | | | When you need to set EXTRA_OECONF for a recipe, you need to know what options the configure script actually supports; the configure script however is only accessible from within a devshell and (at least in the case of autotooled software fetched from an SCM repository) may not actually exist until do_configure has run. Thus, provide a "devtool configure-help" subcommand that runs the configure script for a recipe with --help and shows you the output through a pager (e.g. less), prefaced by a header describing the current options being specified. There is basic support for autotools, cmake and bare configure scripts. The cmake support is a little hacky since cmake doesn't really have a concise help option that lists user-defined knobs (without actually running through the configure process), however that being a design feature of cmake there's not much I can think of to do about that at the moment. (From OE-Core rev: 0e5d84d9705091b338000ef02720cfa090f76888) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: properly handle bb.build.FuncFailed when extracting sourcePaul Eggleton2016-01-261-1/+4
| | | | | | | | | | | | When we run the tasks required to extract the source for a recipe (e.g. within "devtool modify" or "devtool extract") if one of those tasks fails you get a bb.build.FuncFailed exception; handle this properly so you don't see a traceback. (From OE-Core rev: 95d8631b3bdf216001e57f48277535c65a4cc49e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add: warn if modified recipe found in attic directoryPaul Eggleton2016-01-261-0/+3
| | | | | | | | | | | | | | | If a recipe generated by "devtool add" has been modified since then when you run "devtool reset", it will be moved into the "attic" subdirectory of the workspace in case those modifications need to be preserved. It seems natural that if those modifications were worth preserving we should warn the user if such a file exists when they run "devtool add" to create the same recipe again, so they can pick up where they left off if they want to. (From OE-Core rev: 0a39b907ff997c3a62c92ab22325c726b612de5b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: build-image: allow specifying packages to add to imagePaul Eggleton2016-01-261-2/+9
| | | | | | | | | | | | | | | | Provide an option to devtool build-image to specify the list of packages instead of taking the list of packages produced by recipes in the workspace. Sometimes you don't want all of these packages; other times you want to add more. This is the most immediate fix for [YOCTO #8855], though it is a little crude so I would like to provide better means of customising the image contents later. (From OE-Core rev: b3a44951a74fe58714b72e71a7a558b67a71e1e3) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: move edit-recipe to a separate modulePaul Eggleton2016-01-262-36/+70
| | | | | | | | | | standard.py is getting a bit large; move the "utility" commands to another module. (From OE-Core rev: 5089b93f5b341dc28c343f7afe15efda2081ed36) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool / recipetool: support specifying a subdirectory within the fetched ↵Paul Eggleton2016-01-241-0/+6
| | | | | | | | | | | | | | | source Sometimes you don't want to build an entire project, just a subdirectory of it; add a --src-subdir option to make that easier. (We still look for a single subdirectory in what gets unpacked, e.g. what you might find within a tarball, so whatever you specify with this option is added onto the end of that.) (From OE-Core rev: 59682d78f95732e014f78f13e0a05f843860d9bb) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: add sdk-install subcommandPaul Eggleton2016-01-241-1/+62
| | | | | | | | | | | | | | | | | | Add the ability to install additional pre-built items (from shared state) into the extensible SDK. This can already be done implicitly by adding something to DEPENDS within a recipe you're working on and then running "devtool build", but it's useful to be able to explicitly install things particularly if you're using the extensible SDK as a traditional toolchain. Note that for this command to be useful you need to have SSTATE_MIRRORS set in your SDK configuration, and that mirror needs to be populated with sstate artifacts for recipes you wish to be able to install. (From OE-Core rev: 3474a42954908d1688fd3a6cb600eed315b27833) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sdk-update: improve SDK update process robustnessPaul Eggleton2016-01-241-34/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the following improvements to the SDK update process: * Use a manifest file with sha256sums to track files other than sstate and metadata that we need to update - e.g. conf files. This allows us to handle where files such as auto.conf may or may not be present, as well as the configuration changing without affecting task signatures - we still want the config files copied in that case rather than it saying nothing needs to be done. * Write the SSTATE_MIRRORS_append to site.conf rather than local.conf so that local.conf remains static (since we don't want to trigger an update every time). Also, If there is an SSTATE_MIRRORS value already set in the configuration we can skip this and assume it contains the needed packages. * Allow the update process to be run in any directory, don't assume we're already at the base of the SDK * Where practical, fetch remote files into a temporary location and then move them to the desired location at the end, to avoid a failed update leaving the SDK in a broken state. * Update all installed do_populate_sysroot / do_packagedata tasks instead of using the SDK targets. This ensures any item installed through dependencies after installation (e.g. when running "devtool build") won't go stale. (From OE-Core rev: 3d35631121f0e030bc8151f5c23d84008d06f44b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: sdk-update: improve temp directory handlingPaul Eggleton2016-01-241-37/+38
| | | | | | | | | | | | * Use tempfile.mkdtemp() instead of hardcoding temp dir * Set a variable early for the temp locked sigs file and use that everywhere * Delete the temp dir at the end (From OE-Core rev: bad5d1a8c047a8118d30d9fa708b021d1599e0dc) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: build: ensure pkgdata is written outPaul Eggleton2016-01-241-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | When you run devtool build, you need to have the pkgdata written out at the end, so that if what you're adding is a library and the next thing you add is something that depends on that library, the necessary information to map the dependency back to the recipe is present. In practical terms all this means is we need do_packagedata to run in addition to do_populate_sysroot. This does mean that do_package needs to run which wasn't running before, and that means that the few package QA tests that run within do_package such as installed-vs-shipped will now be run. This may be a bit bothersome, and prompted a fix for one of our oe-selftest tests as a result, but I don't see an easy way around it. Ultimately if you care about using the recipe in an image you'll need to fix any such errors anyway. Fixes [YOCTO #8887]. (From OE-Core rev: 6579c7120ee5a541427ff5b6b07f838d52f9fe7c) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/populate_sdk_ext: add option to bring in pkgdata for worldPaul Eggleton2016-01-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a variable SDK_INCLUDE_PKGDATA which you can set to "1" to include pkgdata for all recipes in the world target. There are a couple of uses for this: 1) If you use "devtool add" to add a recipe that builds something which depends on anything in world, the dependency can then be correctly mapped to the recipe providing it and that recipe can be added to DEPENDS, since we have the pkg-config and shared library dependency data within pkgdata. 2) You'll be able to search for these recipes and any files they package for the target with "devtool search" since that also uses pkgdata This of course assumes you've tailored world through EXCLUDE_FROM_WORLD to only include recipes you'd want built in your distro, but I think that's a reasonable assumption; failing that there is a WORLD_PKGDATA_EXCLUDE variable that you can set to exclude any recipes you don't want. Note that this patch relies on functionality implemented in a recent BitBake patch and will not work without it. Implements [YOCTO #8600]. (From OE-Core rev: 67149ea097d6fab7496b43e85a40853f40bd527e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* populate_sdk_ext: Use new --setscene-only option to bitbake instead of ↵Richard Purdie2016-01-111-1/+1
| | | | | | | | | | | workarounds Rather than horrible workarounds, use the new --setscene-only option of bitbake to pre-populate the SDK structures. (From OE-Core rev: 38237b7ac53c416f85c4a70a61acafc3404c8b5f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: build: support using BBCLASSEXTENDed namesPaul Eggleton2016-01-112-7/+23
| | | | | | | | | | | | It's logical that you would want to build BBCLASSEXTENDed items separately through devtool build, so simply allow that - we're just passing the name verbatim to bitbake, so all it means is adjusting the validation. (From OE-Core rev: 25dc5ac42c9da53c01416e7fdcc819d729281133) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: reset: support recipes with BBCLASSEXTENDPaul Eggleton2016-01-112-2/+35
| | | | | | | | | | | If the recipe file itself was created in the workspace, and it uses BBCLASSEXTEND (e.g. through devtool add --also-native), then we need to clean the other variants as well. (From OE-Core rev: e1bf6a30679a83d4dbcf37276204f639541e95f9) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: refactor code for getting local recipe filePaul Eggleton2016-01-111-15/+4
| | | | | | | | | | | 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: add: support adding a native variantPaul Eggleton2016-01-111-0/+3
| | | | | | | | | | | | | | | | Sometimes you need to build a variant of a recipe for the build host as well as for the target (i.e. BBCLASSEXTEND = "native"); add a --also-native command line option to "recipetool create" that enables this and plumb it through from an identical option for "devtool add". (We could conceivably do the same for nativesdk, but I felt it might be confusing within the context of the extensible SDK, where nativesdk isn't really relevant to the user.) (From OE-Core rev: f3bea83db173cce921a9a30f04e88b7e3ed98854) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: reset: do clean for multiple recipes at once with -aPaul Eggleton2016-01-111-11/+14
| | | | | | | | | | | | | | We need to run the clean for all recipes that are being reset before we start deleting things from the workspace; if we don't, recipes providing dependencies may be missing when we come to clean a recipe later (since we don't and couldn't practically reset them in dependency order). This also improves performance since we have the startup startup time for the clean just once rather than for every recipe. (From OE-Core rev: c10a2de75a99410eb5338dd6da0e0b0e32bae6f5) 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-06-30 03:04:50 +0000