The goal is to make this more Pythonic, as it was a little cryptic the
first time I looked at it.
(From OE-Core rev: 80285b0f9b716ebad87a2feb08f12f87d70c27e3)
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ide-sdk command bootstraps the SDK from the bitbake environment
before the IDE configuration is generated. In the case of the eSDK
installer, the bootstrapping is performed during the installation of
the eSDK installer. Running the ide-sdk plugin from an eSDK installer
based setup would require skipping the bootstrapping and probably taking
some other differences into account when generating the IDE
configurations.
This would be possible. But it will probably never be implemented, as
running devtool ide-sdk directly from the bitbake environment is much
more flexible.
Also, some of the recent improvements that have made it into the core
have the potential to make the eSDK installer obsolete at some point in
the future:
- bitbake-layers create-layers-setup replicates the layers
- bitbake-config-build replicates the build configuration
- The new sstate mirror features replicate the sstate
- bblock locks the sstate more flexible than the eSDK installer
- devtool ide-sdk bootstraps the SDK directly from the bitbake
environment. The same environment-setup... file is provided with
--mode=shared.
The devtool modify based workflow is supported since always by devtool
and also the default --mode of devtool ide-sdk.
These functions essentially cover what the eSDK installer does without
a need for the current implementation of the eSDK installer and the
populate_sdk_ext, which is hard to maintain and takes a lot of time to
build.
This means that instead of making the ide-sdk plugin compatible with the
eSDK installer, we should rather replace the current implementation of
the eSDK installer and populate_sdk_ext with an implementation that can
replicate a normal bitbake environment in a convenient way where the
ide-sdk plugin also just works without additional complexity.
(From OE-Core rev: 177aa72b37f2061ff3311ec5dbb33aa56a5ba006)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These imports are not needed.
(From OE-Core rev: c0e9e35843004aaac5bdcc12fa1f6bf8d2da0abb)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also check that 'tools-debug' is not set in
IMAGE_FEATURES to determine if gdbserver is missing.
(From OE-Core rev: 28a8b35826302a40e7bb49f4bd3213fe7026f480)
Signed-off-by: Georgi, Tom <tom.georgi@karlstorz.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debug_build_config function was never called. Compiling with debug
optimized compiler flags was not working. Even with the
--debug-build-config flag set, the build configuration from the recipe
was used.
The devtool ide-sdk --debug-build-config approach didn't work very well
anyway. The problem is that changing the bbappend file doesn't work
while bitbake uses the bbappend file. As a workaround, it would be
possible to parse the recipe, get DEBUG_BUILD and the path to the append
file, exit tinfoil, change the bbappend file, reopen tinfoil and do what
ide-sdk is supposed to do. Such an implementation would be complicated
and slow.
Therefore, the code that was originally supposed to implement this is
removed from ide-sdk and the new --debug-build function of devtool
modify is used instead. Additionally, a hint should be given on how to
manually add DEBUG_BUILD = '1' to bbappend.
This is compatible with the VSCode Bitbake plug-in, which does not
support this parameter anyway.
(From OE-Core rev: 65950eb601c6c8aac0e4bc8683e544305346229d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sort the keys of the generated CMakeUserPreset.json file to make it
easier to search and compare.
(From OE-Core rev: b886c26bf893878ba8eb6bee80dd0507e5cb0d2d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new option --debug-builds to automatically add DEBUG_BUILD = “1”
to the bbappend file of this recipe. This is especially useful when
invoking devtool modify before invoking devtool ide-sdk to perform a
remote debugging session.
(From OE-Core rev: fc17808799d2b667afbe4ea9837b66af70d47007)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't access private variables, instead use the new bb.build.listtasks()
function (from bitbake 185c4b)
(From OE-Core rev: d31a7718c16bd26efd6e174cb5e97fb088aad4bd)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop some unused code.
The actual intention was to look for remnants of S = WORKDIR, which
required the extra complicated oe-local-files directory. The remaining
code dealing with oe-local-files still seems to be useful.
(From OE-Core rev: 02b52a2de3bf5766bc05531138a2e23acb00a276)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When I tried to understand whether oe-local-files is actually still
needed here, I found some useless lines that can be dropped.
(From OE-Core rev: 43f0c6beaa2a99301a565837944250bb2e56c98a)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dropping support for S = WORKDIR allows to drop this ugly workaround.
With S = WORKDIR it was possible to refer to a file via oe-local-files
symlink or via direct file path. Ensuring the pseudo database is
consistent for both paths was extra complicated and required this bad
function. Really nice to drop it now!
(From OE-Core rev: 2b799fdf267f44c26797593984d9828c4fd0fd31)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool modify generates a bbappend for kernel recipes which contains:
SRCTREECOVEREDTASKS="\
do_fetch \
do_kernel_checkout \
do_kernel_configcheck \
do_unpack \
do_validate_branches \
"
do_patch[noexec] = "1"
If the linux-yocto kernel is used, this is redundant. The
linux-yocto.bbclass already does the same:
linux-yocto sets SRCTREECOVEREDTASKS to
SRCTREECOVEREDTASKS="\
do_fetch \
do_kernel_checkout \
do_kernel_configcheck \
do_patch \
do_unpack \
do_validate_branches \
"
Also the do_patch[noexec] is redundant because the purpose of
SRCTREECOVEREDTASKS is to delete these tasks if the externalsrc.bbclass
is used.
The default value of SRCTREECOVEREDTASKS initialized in
externalsrc.bbclass is:
SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
This is fine for kernels which do not inherit the linux-yocto.bbclass.
The code in devtool modify is redundant and therefore removed.
(From OE-Core rev: 94ff1be36a1eeef7ddceb4fcf20425a03cd052de)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop the redundant generation of the do_configure:append section for the
kernel. The same append is generated twice:
if bb.data.inherits_class('kernel', rd):
f.write('\ndo_configure:append() {\n'
' cp ${B}/.config ${S}/.config.baseline\n'
' ln -sfT ${B}/.config ${S}/.config.new\n'
'}\n')
KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= "true"
KCONFIG_CONFIG_ROOTDIR ??= "${B}"
if rd.getVarFlag('do_menuconfig', 'task'):
f.write('\ndo_configure:append() {\n'
' if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then\n'
' cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline\n'
' ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new\n'
' fi\n'
'}\n')
In contradiction to the first code block the second code block considers
the variables which is correct.
(From OE-Core rev: b0733c440e861ed7bf70efdd9b7a73afb4701218)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'UPDATE' as a name is somewhat unfortunate as the variable is intended only for
the 'devtool upgrade' operation and devtool also has an 'update-recipe' operation.
(From OE-Core rev: 4467aa0661e233f44c4ce029428c67d88fccfc07)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BPN isn't correct, as it is set to 'cmake' when 'cmake-native' is being upgraded
(or libva for libva-initial etc.)
(From OE-Core rev: e634316547f86ce5662fa4899440a5af1047d494)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow 'lockstep upgrades' of such recipes, improving success
rates in automated version updating process.
devtool check-upgrade-status now prints:
These recipes need to be upgraded together {
glib-2.0 2.80.2 2.80.4 Anuj Mittal <anuj.mittal@intel.com>
glib-2.0-initial 2.80.2 2.80.4 Anuj Mittal <anuj.mittal@intel.com>
}
These recipes need to be upgraded together {
util-linux 2.39.3 2.40.2 Chen Qi <Qi.Chen@windriver.com>
util-linux-libuuid 2.39.3 2.40.2 Chen Qi <Qi.Chen@windriver.com>
}
These recipes need to be upgraded together {
cmake 3.29.3 3.30.0 Unassigned <unassigned@yoctoproject.org>
cmake-native 3.29.3 3.30.0 Unassigned <unassigned@yoctoproject.org>
}
etc.
(From OE-Core rev: 7874aea5c62be3e8dbd19e04fce5389c5ed7aab6)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Putting various things in a tuple is an anti-pattern of sorts, as the consumers
have to unpack it into local variables for readability, or access items directly
with indexes, which makes code pretty much unreadable.
(From OE-Core rev: e86aa26d209eb9809198f6dd40cd058366318e3d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some recipes, such as those that inherit cargo-update-recipe-crates,
we need to run additional tasks once the new sources have been unpacked.
Introduce a new variable RECIPE_UPDATE_EXTRA_TASKS which is a space-
delimited list of tasks to run after the new sources have been
unpacked in scripts/lib/devtool/upgrade.py ugrade() method.
(From OE-Core rev: 59894f3b5b0bc257837d7ce4ea684f1d8c382cec)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tweak recipetool and devtool to correctly use UNPACKDIR. This allows some
simplification of the code. This patch makes things basically work but there
are likely deeper improvements that can be made now that WORKDIR != UNPACKDIR.
(From OE-Core rev: d2eeaa88b27a2875c419591d1d91bcc85d7b129c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only real reason for oe-local-files was to support S = WORKDIR. With changes to
drop support for that, it makes sense to simplify devtool and to try and make both
the code and the processes/workflows simpler.
This patch drops support for S = WORKDIR, removes oe-local-files and then updates
the test cases to match this new situation.
At the code level, we assume we can always now track code changes using git and
that things committed into git are handled as patches (as before) but delta against
HEAD is saved as specific file level changes to the recipe.
One test is disabled as it is no longer approproate. It is being keped until we can
make WORKDIR != UNPACKDIR at which point it should be revisited.
(From OE-Core rev: ce8190c519052fed10b5233697b69a75868db45a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the git submodule commands failed for source extracted for
recipes using go.bbclass. The root cause is probably the path set up
by go_do_unpack which makes S and gitroot not match.
This patch does not fix the root problem, but at least it is no worse
than before the git submodule support.
The extracted source will still have two .git folders, one in S
created by devtool and one in the go path which will contain the tru
git history.
[ YOCTO #15483 ]
(From OE-Core rev: fe242408af40dd1f6e47d9b2b232bdc76756c80a)
Signed-off-by: Anton Almqvist <antonal@axis.com>
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When trying to use devtool update-recipe/finish on another layer, with modified
local file we have the following error:
Traceback (most recent call last):
File "<..>/poky/scripts/devtool", line 350, in <module>
ret = main()
^^^^^^
File "<..>/poky/scripts/devtool", line 337, in main
ret = args.func(args, config, basepath, workspace)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<..>/poky/scripts/lib/devtool/standard.py", line 1968, in update_recipe
updated, _, _ = _update_recipe(args.recipename, workspace, rd, args.mode, args.append, args.wildcard_version, args.no_remove, args.initial_rev, dry_run_outdir=dry_run_outdir, no_overrides=args.no_overrides, force_patch_refresh=args.force_patch_refresh)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<..>/poky/scripts/lib/devtool/standard.py", line 1930, in _update_recipe
updated, appendf, removed = _update_recipe_patch(recipename, workspace, srctree, crd, appendlayerdir, wildcard_version, no_remove, no_report_remove, initial_rev, dry_run_outdir, force_patch_refresh)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "<..>/poky/scripts/lib/devtool/standard.py", line 1747, in _update_recipe_patch
patchdir = param.get('patchdir', ".")
^^^^^^^^^
AttributeError: 'str' object has no attribute 'get'
This was introduced when adding support for git submodules.
No selftest case exists to catch this, so a selftest will be
added in another commit.
(From OE-Core rev: de7ca9f800e15e10271502da7e51e3ae08e0c85b)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When executing devtool sync on a recipe that was extract with devtool
extract earlier the following error occured:
Traceback (most recent call last):
[...]
bb.process.ExecutionError: Execution of 'git fetch file:///home/vin/projects/poky/build/tmp/work/all-poky-linux/netbase/6.4/devtooltmp-figt1jmr/workdir/netbase devtool:devtool' failed with exit code 128:
fatal: refusing to fetch into branch 'refs/heads/devtool' checked out at '/home/vin/projects/poky/build/netbase-src'
Fix this by adding --update-head-ok and --force to git fetch so it will
override the current head even if it is checked out and has changes.
Possible existing changes in the devtool branch can be retrieved by
checking out the devtool.bak branch
(From OE-Core rev: 4c89b061003a0f4143c6d3838e39fc2643edc8d6)
Signed-off-by: Vincent Kriek <vincent@coelebs.dev>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If source is in detached HEAD, we get the following error when using
detvool finish command:
[...]
File "<...>/poky/scripts/lib/devtool/standard.py", line 1938, in _update_recipe
bb.process.run('git checkout %s' % startbranch, cwd=srctree)
File "<...>/poky/bitbake/lib/bb/process.py", line 189, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git checkout (HEAD detached at 9bbf87e)' failed with exit code 2:
/bin/sh: -c: line 1: syntax error near unexpected token `('
/bin/sh: -c: line 1: `git checkout (HEAD detached at 9bbf87e)'
Check this and throws an appropriate error in this case
(From OE-Core rev: d9c686b5ff9f591ec6b928ed539084c02df4c8a5)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the previous commit:
- log an error if some assumptions are not true
- Use TARGET_DBGSRC_DIR variable
- Do the same for ide none
Why the additional source mapping is required:
For example the cmake-example recipe refers to sources like this:
./recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-readelf \
-wi image/usr/bin/cmake-example | grep -B1 DW_AT_comp_dir
...
<560> DW_AT_name : (indirect line string, offset: 0x1da):
/usr/src/debug/cmake-example/1.0/oe-local-files/cpp-example.cpp
...
Another example is powertop:
./recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-readelf \
-wi image/usr/sbin/powertop | grep -B1 DW_AT_comp_dir
...
<561> DW_AT_name : (indirect line string, offset: 0x1da):
/usr/src/debug/powertop/2.15/src/devlist.cpp
...
For recipes with local files this works. The oe-local-files folder is
not available in the rootfs-dbg and therefore the sources are first
found in the workspace folder. GDB searches for source files in various
places:
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Source-Path.html
However, for the powertop example the sources opened in the editor are
from the rootfs-dbg instead of from the workspace.
Bitbake calls the compiler with
-fmacro-prefix-map=${S}=${TARGET_DBGSRC_DIR}
where TARGET_DBGSRC_DIR defaults to "/usr/src/debug/${PN}/${PV}".
A source map which maps the recipe specific path from TARGET_DBGSRC_DIR
to the workspace fixes this.
The already existing source map for /usr/src/debug applies for all other
recipes. It finds the sources (read only) in the rootfs-dbg folder.
(From OE-Core rev: 06601632c1879cb80276f9b36de91fb7808311a5)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When launching the debug configuration, the source files from the debug
rootfs were openened in the editor instead of the local workspace files.
We add an exception to properly map them to the file being developed and
compiled by the IDE integration. This also more closely matches what the
user would expect compared to native development.
This is also true for the devtool fallback mode.
(From OE-Core rev: 24db2b8d0d7104960c1cdb2c7ee5216c830a6754)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If multiple recipes are processed at once, the launch.json and the
tasks.json of the second recipe contains also the configurations for the
binaries of the first recipe.
Example:
devtool ide-sdk powertop cmake-example oe-selftest-image
generated a launch and a tasks configuration for the cmake-example
recipe which also offers debugging the powertop binary.
(From OE-Core rev: 63986b2c40d90fe96cdc6a46aa649efcf17f6ac2)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The compile_commands.json file output by meson uses the compiler as if
present in the $PATH. However, when using an IDE, the $PATH used by
bitbake is not there.
The vscode-cpptools now allows to define the compilerPath in addition
to replace the one from compile_commands.json.
(From OE-Core rev: d9f5c27c8beee07c7cbbed11f5d45058e7315846)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When debugging or browsing files, the user may fall into external
sources from other packages in the sysroot or dbg-rootfs. Modifying them
will only lead to confusion since they will be overwritten by Yocto. The
user should open them in a separate devtool modify session if they want
to make changes. Meanwhile, we should prevent write access to them.
(From OE-Core rev: 8a95ad9aecb81732c865e00a987bb8bd3d6cb91d)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The generated scripts use the sys.path configuration found inside
bitbake. It can be a different python version than the one used on the
host through the IDE.
For instance, when running the generated script
deploy_target_cmake-example-core2-64 from an eSDK generated on another
machine, I got the following exception:
AssertionError: SRE module mismatch
We need to match the sys.executable to the sys.path.
(From OE-Core rev: 45704319661570b45ef69fddd6b4b4fa22ca80d1)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The old way of keeping track of the filenames for the patches that
correspond to the commits was to add a special comment line to the end
of the commit message, e.g., "%% original patch: <filename>", using a
temporary git hook. This method had some drawbacks, e.g.:
* It caused problems if one wanted to push the commits upstream as the
comment line had to be manually removed.
* The comment line would end up in patches if someone used git
format-path rather than devtool finish to generate the patches.
* The comment line could interfere with global Git hooks used to
validate the format of the Git commit message.
* When regenerating patches with `devtool finish --force-patch-refresh`,
the process typically resulted in adding empty lines to the end of the
commit messages in the updated patches.
A better way of keeping track of the patch filenames is to use Git
notes. This way the commit messages remain unaffected, but the
information is still shown when, e.g., doing `git log`. A special Git
notes space, refs/notes/devtool, is used to not intefere with the
default Git notes. It is configured to be shown in, e.g., `git log` and
to survive rewrites (i.e., `git commit --amend` and `git rebase`).
Since there is no longer any need for a temporary Git hook, the code
that manipulated the .git/hooks directory has also been removed. To
avoid potential problems due to global Git hooks, --no-verify was added
to the `git commit` command.
To not cause troubles for those who have done `devtool modify` for a
recipe with the old solution and then do `devtool finish` with the new
solution, the code will fall back to look for the old strings in the
commit message if no Git note can be found.
While not technically motivated like above, the way to keep track of
ignored commits is also changed to use Git notes to avoid having
different methods to store similar information.
(From OE-Core rev: f5e6183b9557477bef74024a587de0bfcc2b7c0d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes use of the oe.patch.GitApplyTree.commitIgnored() function to
create commits that shall be ignored by `devtool finish`.
(From OE-Core rev: 4e1b9289450b5e7946bd5999c95a3ee214aab8a5)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also correct the comment describing what is happening.
(From OE-Core rev: 7d867753fba8d536bef4c72c7bea3f4ed26a1a95)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Makes it a little bit easier when reading the code.
(From OE-Core rev: 6a757f9648685448fd18507f6aaf4eed0a57579f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new devtool ide plugin provides the eSDK and configures an IDE to
work with the eSDK. In doing so, bitbake should be used to generate the
IDE configuration and update the SDK, but it should no longer play a
role when working on the source code. The work on the source code should
take place exclusively with the IDE, which, for example, calls cmake
directly to compile the code and execute the unit tests from the IDE.
The plugin works for recipes inheriting the cmake or the meson bbclass.
Support for more programming languages and build tools may be added in
the future.
There are various IDEs that can be used for the development of embedded
Linux applications. Therefore, devtool ide-sdk, like devtool itself,
supports plugins to support IDEs.
VSCode is the default IDE for this first implementation. Additionally,
some generic helper scripts can be generated with --ide none instead of
a specific IDE configuration. This can be used for any IDE that
supports calling some scripts.
There are two different modes supported:
- devtool modify mode (default):
devtool ide-sdk configures the IDE to manage the build-tool used by the
recipe (e.g. cmake or meson). The workflow looks like:
$ devtool modify a-recipe
$ devtool ide-sdk a-recipe a-image
$ code "$BUILDDIR/workspace/sources/a-recipe"
Work in VSCode, after installing the proposed plugins
Deploying the artifacts to the target device and running a remote
debugging session is supported as well.
This first implementation still calls bitbake and devtool to copy the
binary artifacts to the target device. In contrast to compiling,
installation and copying must be performed with the file rights of the
target device. The pseudo tool must be used for this. Therefore
bitbake -c install a-recipe && devtool deploy-target a-recipe
are called by the IDE for the deployment. This might be improved later
on.
Executing the unit tests out of the IDE is supported via Qemu user if
the build tool supports that. CMake (if cmake-qemu.bbclass is
inherited) and Meson support Qemu usermode.
- Shared sysroots mode: bootstraps the eSDK with shared sysroots for
all the recipes passed to devtool ide-sdk. This is basically a wrapper
for bitbake meta-ide-support && bitbake build-sysroots. The workflow
looks like:
$ devtool ide-sdk --share-sysroots a-recipe another-recipe
vscode where/the/sources/are
If the IDE and the build tool support it, the IDE gets configured to
offer the cross tool-chain provided by the eSDK. In case of VSCode and
cmake a cmake-kit is generated. This offers to use the cross
tool-chain from the UI of the IDE.
Many thanks to Enguerrand de Ribaucourt for testing and bug fixing.
(From OE-Core rev: 3f8af7a36589cd05fd07d16cbdd03d6b3dff1f82)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A missing space when using :append would lead to run-on URIs if there
was no whitespace at the end of the original SRC_URI.
(From OE-Core rev: 4de0c679e4b1a3cb394f348d625b97ad73f1efe7)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the deploy function independent from d. This allows to call the
function also from Python code not running in bitbake.
This is needed to for the devtool ide plugin which will call the
do_install task and the code from devtool deploy-target independently
from a bitbake server. This allows a much quicker workflow.
(From OE-Core rev: c8697d1132cbd4b2a2502b4c48e7d91fc18de786)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a step towards a deploy function which can be called without
passing the d variable.
(From OE-Core rev: 3e8c41ec373a1766f68932d3b979d00e4e3bb3a9)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provide a function exec_fakeroot_no_d which does the same like
exec_fakeroot does, but is usable independenlty from bitbake. This
allows to use the fanction from scripts where the d variable is not
available.
(From OE-Core rev: 6f5980d96844559639fc3660bb975b0bdd1aa523)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #15162]
when doing devtool modify, sources are extracted into a devtool
temporary workdir. The main source is moved inside
build/workspace/sources/${BPN}/ and local files are moved inside
build/workspace/sources/${BPN}/oe-local-files. Secondary sources are
currently not handled and are lost.
Here is the output of devtool modify/build on bzip2 recipe:
NOTE: bzip2: compiling from external source tree <...>/build/workspace/sources/bzip2
ERROR: bzip2-1.0.8-r0 do_install_ptest_base: ExecutionError('<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368', 1, None, None)
ERROR: Logfile of failure stored in: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/log.do_install_ptest_base.3368
Log data follows:
| DEBUG: Executing shell function do_install_ptest_base
| NOTE: make -j 16 DESTDIR=<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest install-ptest
| sed -n '/^runtest:/,/^install-ptest:/{/^install-ptest:/!p}' \
| ../../../../../../workspace/sources/bzip2/Makefile.am > <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/Makefile
| cp ../../../../../../workspace/sources/bzip2/sample1.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.ref <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample1.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample2.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| cp ../../../../../../workspace/sources/bzip2/sample3.bz2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/
| ln -s /usr/bin/bzip2 <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2
| cp: cannot stat '<...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/git/commons-compress': No such file or directory
| WARNING: <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368:189 exit 1 from 'cp -r <...>/build/tmp/work/core2-64-poky-linux/bzip2/
1.0.8/git/commons-compress <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/image/usr/lib/bzip2/ptest/bzip2-tests/commons-compress'
| WARNING: Backtrace (BB generated script):
| #1: do_install_ptest, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 189
| #2: do_install_ptest_base, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 158
| #3: main, <...>/build/tmp/work/core2-64-poky-linux/bzip2/1.0.8/temp/run.do_install_ptest_base.3368, line 226
ERROR: Task (<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base) failed with exit code '1'
NOTE: Tasks Summary: Attempted 776 tasks of which 765 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
<...>/poky/meta/recipes-extended/bzip2/bzip2_1.0.8.bb:do_install_ptest_base
externalsrc class modify SRC_URI to keep only:
* 'file', 'npmsw' and 'crate' sources
* url with type parameter matching 'kmeta' or 'git-dependency'
So by forcing to add type='git-dependency' on secondary sources, we
ensure that when building the recipe, the secondary sources can be
unpacked into WORKDIR.
This allows recipes containing several sources to be built under a
devtool context, but it has some limitations:
* user would not be able to generate patches for the secondary sources
* type="git-dependency" is added for secondary sources even on non git
sources, so we may want to rename this parameter
(From OE-Core rev: cfd5ee890163a3d975093359016dda104e7b71df)
Signed-off-by: Julien Stephan <jstephan@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Root Cause:
initial_revs is an empty dictionary and do not have "." key.
Traceback (most recent call last):
File "scripts/devtool", line 349, in <module>
ret = main()
File "scripts/devtool", line 336, in main
ret = args.func(args, config, basepath, workspace)
File "scripts/lib/devtool/standard.py", line 922, in modify
if not initial_revs["."]:
KeyError: '.'
Solution:
check key exists, then get its value.
(From OE-Core rev: fb0db5c48abb4d56233a175fdd349d18b972e452)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'devtool check-upgrade-status' is for reporting upgradable
status for recipes. The output should always be printed out. So
we should just use 'print' instead of 'logger.info' as the latter
will be suppressed if '-q' parameter is supplied to devtool.
(From OE-Core rev: 2c7bf9c8a833bec13a1ebabdce30933cbe691108)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
