| Age | Commit message (Collapse) | Author | Files |
|---|
|
When we were adding a recipe for software that would typically be built
in the same directory as the source, we were always using a separate
build directory unless the user explicitly specified not to, leading to
errors for software that doesn't expect to be built that way (such as
Python modules using distutils). Split out the code that makes this
determination automatically from the "devtool modify" and "devtool
upgrade" code and re-use that here so the behaviour is consistent.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These functions ostensibly allowed parsing a recipe without bbappends
but this clearly hadn't been tested because a variable was unassigned in
both of them in that case.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
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>
|
|
This is not actually used for anything - I thought that we would need to
use it within devtool to set global configuration, but we're able to do
everything we need within the bbappends it creates, which also saves on
parse time. If we're not going to use work-config.inc let's just drop it
completely.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Use already existing bb.fetch.decodeurl() for getting the parameters for
a URI. This is more fault tolerant and maintainable.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
So far all devtool and recipetool plugins were expected
to have plugin_init function. This function is empty in
most of plugins as they don't require initialisation.
Making plugin_init optional would allow not having empty
plugin_init in every plugin.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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>
|
|
If a recipe has been added to the workspace via "devtool add"
or "devtool upgrade" then the recipe file itself will be in the
workspace layer; if you run "devtool update-recipe" particularly in the
upgrade case you might think it would apply the upgrade to the original
recipe, but it will not - in order to remain consistent it has to update
the recipe that's in use which is the one in the workspace. Warn the
user in this situation so that they know what they need to do when they
are finished.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Enhance the logic behind the 'auto' mode a bit by only updating the
SRCREV if the changes are already found upstream. The logic is simple:
update SRCREV only if the current local HEAD commit is found in the
remote branch (i.e. 'origin/<branch_name>'). Otherwise resort to
patching.
This affects a couple of the oe-selftest tests so update those as well.
[YOCTO #7907]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Through -s/--disable-parallel-make, the user can turn off parallelism
on the make tool. This can be useful when debuging race condition issues.
In order to set PARALLEL_MAKE = "" a post-config file created and then
passed into the build.
[YOCTO #7589]
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The intention is to have a single file for each devtool feature
so devtool can grow in a modular way. In this direction, this patch creates
build.py, moving all related build features from standard.py to build.py.
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Upgrades a recipe to a particular version and downloads the source code
into a folder. User can avoid patching the source code.
These are the general steps of the upgrade function:
- Extract current recipe source code into srctree and create a branch
- Extract upgrade recipe source code into srctree and rebase with
previous branch. In case the rebase is not correctly applied, source
code will not be deleted, so user correct the patches
- Creates the new recipe under the workspace
[YOCTO #7642]
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Allow the _add_md5() function to be called with a directory in order to
recursively add the files under it. Additionally, we need to skip
preserving empty directories (since directories aren't listed in the md5
file).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Do not put 'do_shared_workdir' into SRCTREECOVEREDTASKS when creating
bbappend for kernel packages. This will allow building packages that
depend on the shared build artifacts of kernel.
[YOCTO #6658]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Enable updating the installed extensible SDK from a local or remote
server, avoiding the need to install it again from scratch when
updating. (This assumes that the updated SDK has been built and then
published somewhere using the oe-publish-sdk script beforehand.)
This plugin is only enabled when devtool is used within the extensible
SDK since it doesn't make sense to use it next to a normal install of
the build system.
E.g.
devtool sdk-update /mnt/sdk-repo/
devtool sdk-update http://mysdkhost/sdk
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The kernel package needs "kern-tools-native" in order for it's
do_kernel_metadata. Thus, devtool extract for kernel in a pristine
environment fails. With the current bb.tinfoil implementation it is not
possible to run arbitrary bitbake commands - e.g. run
"bitbake kern-tools-native -c populate_sysroot" in our case. This patch
implements an ugly workaround for that problem, basically by hardcoding
this dependency and running the required bitbake task(s) before tinfoil
is initialized.
[YOCTO #6658]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Change handling of kernel packages so that the "initial rev" is parsed
correctly. Also, the devtool-specific git tags (devtool-base and
devtoo-patched) are now generated for kernel packages as well.
[YOCTO #6658]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Set SRCTREECOVEREDTASKS appropriately in the workspace .bbappend file
for kernel recipes. This tries to ensure that all needed tasks (esp.
configure and patch) are run when building the kernel - tasks which
would normally be disabled by externalsrc.bbclass.
[YOCTO #6658]
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Added couple of hopefully useful comments to the code.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Removed <image>.bbappend before generating it again as
it may cause tinfoil to fail due to its wrong content.
It's safe to do as <image>.bbappend is regenerated anyway.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Added logger calls to show if image is modified by the
plugin or not.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Added notification callback to <image>.bbapend to notify
user that image is modified by build-image plugin.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Filtered out non-target recipes and recipes with
recipe name != package name in build-image plugin.
Isolated all logic of getting recipes in _get_recipes
function.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Made parser help message and description more clear in
build-image plugin.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Used logger variable name instead of LOG as it is used the rest
of the devtool code.
Pylint complains about 'logger' being invalid constant name,
but it's better to be consistent in naming.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
This reverts commit 69c63728dae38d5b1cc9874268f235a07e04d3db.
Moved add_md5 back to standard.py as it's not used in
any plugin anymore.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Moved standard.py:_parse_recipe -> __init__.py:parse_recipe and
standard.py:_get_recipe_file -> __init__.py:get_recipe_file
to be able to call them from other modules.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
It doesn't make sense to use it as image recipe is not
in workspace. It means that we can't do 'devtool reset'
for the recipe, which is a main point of using add_md5.
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
|
|
Implemented new plugin to build image from workspace packages.
Plugin creates <image>.bbappend file, adds
all workspace packages to the image using IMAGE_INSTALL_append
variable in bbappend file. After that it runs 'bitbake <image>'.
(From OE-Core rev: 00bc43868da3ea2a4532215d3abef8e150c7b2e5)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Moved _add_md5 function from standard.py to __init__.py to
be able to call it from other modules.
(From OE-Core rev: ee38bb20dc7ba21dac782d8d13383f81dfedef55)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Let's have the caller do this and then the function is a bit more
flexible (e.g. we can choose to parse with bbappends or not); fix up
calls to this function appropriately (of which there are only two, both
within devtool).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Ensure that the "patches" subdirectory is removed from the right
location when S == WORKDIR (e.g. devtool extract makedevs).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
In case the user has set up externalsrc outside of devtool, force
EXTERNALSRC to blank for the recipe when extracting so that the original
source URI is still in SRC_URI and we're still able to extract it. (This
isn't a problem with devtool itself because the bbappends within the
workspace layer that apply externalsrc are explicitly filtered out when
devtool parses a recipe).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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]
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
If patches fail to apply with git, quilt it used as a fallback. If that
happens, the code in this class is meant to handle cleanup of these patch
files. In the case where ${S} is a subdir of the git tree, the code doesn't
correctly set the patches directory.
This change correctly sets the patches directory (which is different to the
location of the git repository).
[YOCTO #7911]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
It turns out that scp can't be used to copy symlinks because it follows
them instead of copying them, and this is by design (since it emulates
rcp which also behaved this way); the unfortunate result is that
symlinks that point to valid files on the host translate into the host
file being copied to the target (yuck). The simplest alternative that
does not have this undesirable behaviour is to use tar and pipe it over
ssh.
At the same time, it would be even better if we properly reflect file
permissions and ownership on the target that have been established
within the pseudo environment. We can do this by executing the copy
process under pseudo, which turns out to be quite easy with access to
the pseudo environment set up by the build system.
Fixes [YOCTO #7868].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Continue refactoring of update_recipe() by splitting out the 'patch'
mode into a separate function.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Refactor update_recipe() (i.e. the implementation of the update-recipe
command) by splitting out the 'srcrev' into a distinct function.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Just refactor the code.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
A slight simplification of the code.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Split out the logic of determining "initial rev" and "update rev" into a
separate function.
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
|
|
Quite often what you want to do having made customisations to a piece of
software is to apply those customisations in your own layer rather than
in the original recipe. Thus, add a -a/--append option to the
update-recipe subcommand which allows you to specify the layer to write
a bbappend into. The bbappend will be created at the appropriate path
within the specified layer directory (which may or may not be in your
bblayers.conf) or if one already exists it will be updated
appropriately.
(This re-uses code written for recipetool appendfile.)
Implements [YOCTO #7587].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Most of the time when bb.note() gets called we want to see the output,
so ensure the level is set appropriately depending on the command line
options instead of being fixed at warning. (We don't want to see the
notes for fetch/unpack/patch though as they are too verbose).
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
