summaryrefslogtreecommitdiffstats
path: root/meta/classes/devtool-source.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* devtool: fix modify with patches in override directoriesRoss Burton2020-10-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | If a recipe applies patches which are in machine-specific override directories, devtool will fail to fetch the patches that don't match the default configuration. For example where there are patches at qemux86/x86.patch and qemuarm/arm.patch: SRC_URI = "file://source" SRC_URI_append_qemuarm = " file://arm.patch" SRC_URI_append_qemux86 = " file://x86.patch" The patch apply phase sets OVERRIDES but does not set FILESOVERRIDES, so it cannot find the patch files as the search path isn't correct. Fix this by setting FILESOVERRIDES too. Also when iterating through the overrides we need to be sure that other overrides that are used are not enabled, so extend no_overrides instead of simply appending the current override. Fixes most but not all of [ YOCTO #14060 ]. (From OE-Core rev: a372cdf8e175423c47faeecc98ad076ee26bbec8) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool-source.bbclass: Use with to manage file handle lifetimeOla x Nilsson2019-10-231-5/+3
| | | | | | | | | Replace copy-and-if with a filtering list comprehension. (From OE-Core rev: eb763856be8da854d37c7d4b8e8d645ab1d3fa06) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: Support kmeta directory usage with devtool modify/finishJaewon Lee2019-03-061-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using Kmeta directories, devtool finish will add every single file in the directory to the bbappend. This is because in the current implementation, the get_recipe_local_files function treats the kmeta directory like a file. Modifying the function to loop through the provided directories and return all included files instead of just the top level directory. This will enable correct file to file comparison when determing which files are new/changed and need to be added to the bbappend. Adding an extra check in devtool-source.bbclass to not copy the cfg file if its already included somewhere in the kmeta directory Also during 'modify', when moving necessary files in the kmeta directory from the workdir to oe-local-files, the dangling parent directories are left behind. This in itself is not an issue as the temporary devtool workspace is automatically deleted, but this causes an incorrect include directory to be added in kernel-yocto.bbclass. Changing the order of the if statements to catch the correct conditional. This is safe to do as when not in the devtool context, there will be no oe-local-files directory. (From OE-Core rev: 4671011b5b02d0989aa0fdcb50e18cb385a0e95e) Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com> Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com> Acked-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool-source.bbclass: Only create each patch branch onceOlof Johansson2018-10-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | For conditonally applied patches based on SRC_URI overrides, the devtool-source class would try to create a new branch for each override assignment as a postfunc to do_patch, but if the same override was used multiple times, it would try to create the same branch multiple times, causing errors like > Exception: bb.process.ExecutionError: Execution of \ 'git checkout f0f0f0f0f0ff0f0f0f0f0f0f0f0f0f0f0ff0f0f0 -b devtool-override-foo' \ failed with exit code 128: > fatal: A branch named 'devtool-override-foo' already exists. This change makes sure that the devtool-source bbclass will only create one branch per override. (From OE-Core rev: 95a921959d340f74b5604df57737c1eeaad0023e) Signed-off-by: Olof Johansson <olofjn@axis.com> Reviewed-by: Peter Kjellerstedt <pkj@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool-source.bbclass: Support kernel-fragments/patch not in SRC_URIJaewon Lee2018-08-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using a recipe space kernel-meta, scc files are added through SRC_URI, but they may include corresponding kernel fragments or patches that are not necessarily in SRC_URI. For bitbake, this is not a problem because the kernel-yocto class adds the path where the .scc file was found to includes which consequentially makes the .cfg, .patch file available to the kernel build. However, when using devtool, only files specified in SRC_URI are copied to oe-local-files in devtool's workspace. So if the cfg/patch file is not in SRC_URI, it won't be copied, causing a kernel build failure when trying to find it. This fix parses local .scc files in SRC_URI, copies the corresponding .cfg/.patch file to devtool's workdir, and also adds it to local_files so it is available when doing a devtool build for the kernel. [YOCTO #12858] v2: also supporting patch not in SRC_URI v3: fix spacing issues (From OE-Core rev: 5dffd5403664dfcc9e8e42fd3581d5cb70823d7e) Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com> Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: implement conditional patch handlingPaul Eggleton2017-11-111-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have a recipe that uses overrides to conditionally extend SRC_URI to add additional patches, then you will often need to update those patches if you're making other changes to the source tree (for example if you're upgrading the underlying source). Make this possible with devtool by creating devtool-override-* branches for each override that conditionally appends/prepends SRC_URI, and have devtool update-recipe / finish check each branch out in turn and update the corresponding patches. A current example of a recipe that does this is the quota recipe - it applies an additional patch if musl is the selected C library (i.e. libc-musl is in OVERRIDES). Note that use of this functionality does require some care - in particular, updates to patches that appear on the main branch (named "devtool" by default) should be made there and not only on one of the specific devtool-override-* branches that are created for each override. The recommended procedure is to make the changes you want to make to the main branch first, then check out and rebase each devtool-override-* branch, testing each one by activating the corresponding configuration, and then finally run devtool finish. Fixes [YOCTO #11516]. (From OE-Core rev: aa87603d1ffd695027847f4df75c0406cf4e14d8) 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: rework source extraction so that dependencies are handledPaul Eggleton2017-09-181-0/+165
Since it was first implemented, devtool's source extraction (as used by the devtool modify, extract and upgrade subcommands) ignored other recipe dependencies - so for example if you ran devtool modify on a recipe that fetches from svn or is compressed using xz then it would fail if those dependencies hadn't been built first. Now that we can execute tasks in the normal way (i.e. tinfoil.build_targets()) then we can rework it to use that. This is slightly tricky in that the source extraction needs to insert some logic in between tasks; luckily we can use a helper class that conditionally adds prefuncs to make that possible. Some side-effects / aspects of this change worth noting: * Operations are a little slower because we have to go through the task dependency graph generation and other startup processing. There's not really any way to avoid this though. * devtool extract didn't used to require a workspace, now it does because it needs to create a temporary bbappend for the recipe. (As with other commands the workspace be created on the fly if it doesn't already exist.) * I want any existing sysroot files and stamps to be left alone during extraction since we are running the tasks off to the side, and especially devtool extract should be able to be used without touching these. However, this was hampered by the automatic removal process in sstate.bbclass triggered by bb.event.ReachableStamps when the task signatures change, thus I had to introduce a way to disable this removal on a per-recipe basis (we still want it to function for any dependencies that we aren't working on). To implement this I elected to use a file written to tmp/sstate-control which gets deleted automatically after reading so that there's less chance of stale files affecting future sessions. I could have used a variable but this would have needed to be whitelisted and I'd have to have poked its value in using the setVariable command. Fixes [YOCTO #11198]. (From OE-Core rev: 830dbd66992cbb9e731b48d56fddf8f220349666) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>