Devtool

[Najee Laboy]

Insteadof using the devtool option you can also use SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin directly as it has more options. Never use both the devtool option and plugin together. The devtool option adds the plugin internally so you would end up with the plugin applied twice.

Some of these values are suited for development and some for production. For development you typically want fast Source Maps at the cost of bundle size, but for production you want separate Source Maps that are accurate and support minimizing.

without source content - Contents for the sources are not included in the Source Maps. Browsers usually try to load the source from the webserver or filesystem. You have to make sure to set output.devtoolModuleFilenameTemplate correctly to match source urls.

(lines only) - Source Maps are simplified to a single mapping per line. This usually means a single mapping per statement (assuming you author it this way). This prevents you from debugging execution on statement level and from settings breakpoints on columns of a line. Combining with minimizing is not possible as minimizers usually only emit a single line.

eval - Each module is executed with eval() and //# sourceURL. This is pretty fast. The main disadvantage is that it doesn't display line numbers correctly since it gets mapped to transpiled code instead of the original code (No Source Maps from Loaders).

eval-source-map - Each module is executed with eval() and a SourceMap is added as a DataUrl to the eval(). Initially it is slow, but it provides fast rebuild speed and yields real files. Line numbers are correctly mapped since it gets mapped to the original code. It yields the best quality SourceMaps for development.

eval-cheap-source-map - Similar to eval-source-map, each module is executed with eval(). It is "cheap" because it doesn't have column mappings, it only maps line numbers. It ignores SourceMaps from Loaders and only display transpiled code similar to the eval devtool.

eval-cheap-module-source-map - Similar to eval-cheap-source-map, however, in this case Source Maps from Loaders are processed for better results. However Loader Source Maps are simplified to a single mapping per line.

hidden-source-map - Same as source-map, but doesn't add a reference comment to the bundle. Useful if you only want SourceMaps to map error stack traces from error reports, but don't want to expose your SourceMap for the browser development tools.

nosources-source-map - A SourceMap is created without the sourcesContent in it. It can be used to map stack traces on the client without exposing all of the source code. You can deploy the Source Map file to the webserver.

One more info, if I try to populate sdk ext for core-image-minimal from poky using verdin-imx8mp machine with tdx-xwayland-rt distro:

clear; DISTRO="tdx-xwayland-rt" bitbake core-image-minimal -c populate_sdk_ext

Thank you for the reply, this approach is new to me, it seems that I can continue my tasks with that way. But we need to provide a SDK to software developers in the company so that they can also continue their developments.

The devtool command-line tool provides a number of features that help you build, test, and package software. This command is available alongside the bitbake command. Additionally, the devtool command is a key part of the extensible SDK.

The devtool command-line tool provides a number of features thathelp you build, test, and package software. This command is availablealongside the bitbake command. Additionally, the devtool commandis a key part of the extensible SDK.

Running devtool add when the workspace layer exists causes the toolto add the recipe, append files, and source files into the existingworkspace layer. The .bbappend file is created to point to theexternal source tree.

By default, devtool add uses the latest revision (i.e. master) whenunpacking files from a remote URI. In some cases, you might want tospecify a source revision by branch, tag, or commit hash. You canspecify these options when using the devtool add command:

Use the devtool extract command to extract the source for anexisting recipe. When you use this command, you must supply the rootname of the recipe (i.e. no version, paths, or extensions), and you mustsupply the directory to which you want the source extracted.

Use the devtool sync command to synchronize a previously extractedsource tree for an existing recipe. When you use this command, you mustsupply the root name of the recipe (i.e. no version, paths, orextensions), and you must supply the directory to which you want thesource extracted.

Use the devtool modify command to begin modifying the source of anexisting recipe. This command is very similar to theadd commandexcept that it does not physically create the recipe in the workspacelayer because the recipe already exists in an another layer.

The devtool modify command extracts the source for a recipe, sets itup as a Git repository if the source had not already been fetched fromGit, checks out a branch for development, and applies any patches fromthe recipe as commits on top. You can use the following command tocheckout the source files:

When you use the devtool edit-recipe command, you must supply theroot name of the recipe (i.e. no version, paths, or extensions). Also,the recipe file itself must reside in the workspace as a result of thedevtool add or devtool upgrade commands.

Use the devtool update-recipe command to update your recipe withpatches that reflect changes you make to the source files. For example,if you know you are going to work on some code, you could first use thedevtool modify command to extractthe code and set up the workspace. After which, you could modify,compile, and test the code.

Often, you might want to apply customizations made to your software inyour own layer rather than apply them to the original recipe. If so, youcan use the -a or --append option with thedevtool update-recipe command. These options allow you to specifythe layer into which to write an append file:

The *.bbappend file is created at theappropriate path within the specified layer directory, which may or maynot be in your bblayers.conf file. If an append file already exists,the command updates it appropriately.

To check on the upgrade status of a recipe, you can use thedevtool latest-version recipe command, which quickly shows the currentversion and the latest version available upstream. To get a more globalpicture, use the devtool check-upgrade-status command, which takes alist of recipes as input, or no arguments, in which case it checks allavailable recipes. This command will only print the recipes for whicha new upstream version is available. Each such recipe will have its currentversion and latest upstream version, as well as the email of the maintainerand any additional information such as the commit hash or reason for notbeing able to upgrade it, displayed in a table.

This upgrade checking mechanism relies on the optional UPSTREAM_CHECK_URI,UPSTREAM_CHECK_REGEX, UPSTREAM_CHECK_GITTAGREGEX,UPSTREAM_CHECK_COMMITS and UPSTREAM_VERSION_UNKNOWNvariables in package recipes.

Notice the reported reason for not upgrading the base-passwd recipe.In this example, while a new version is available upstream, you do notwant to use it because the dependency on cdebconf is not easilysatisfied. Maintainers can explicit the reason that is shown by addingthe RECIPE_NO_UPDATE_REASON variable to the corresponding recipe.See base-passwd.bbfor an example:

When you use the devtool upgrade command, you must supply the rootname of the recipe (i.e. no version, paths, or extensions), and you mustsupply the directory to which you want the source extracted. Additionalcommand options let you control things such as the version number towhich you want to upgrade (i.e. the PV), the sourcerevision to which you want to upgrade (i.e. theSRCREV), whether or not to apply patches, and soforth.

Use the devtool reset command to remove a recipe and itsconfiguration (e.g. the corresponding .bbappend file) from theworkspace layer. Realize that this command deletes the recipe and theappend file. The command does not physically move them for you.Consequently, you must be sure to physically relocate your updatedrecipe and the append file outside of the workspace layer before runningthe devtool reset command.

When you use the devtool build command, you must supply the rootname of the recipe (i.e. do not provide versions, paths, or extensions).You can use either the -s or the --disable-parallel-make options todisable parallel makes during the build. Here is an example:

Use the devtool build-image command to build an image, extending itto include packages from recipes in the workspace. Using this command isuseful when you want an image that ready for immediate deployment onto adevice for testing. For proper integration into a final image, you needto edit your custom image recipe appropriately.

This command deploys all files installed during thedo_install task. Furthermore, you do notneed to have package management enabled within the target machine. Ifyou do, the package manager is bypassed.

Some conditions could prevent a deployed application frombehaving as expected. When both of the following conditions are met, yourapplication has the potential to not behave correctly when run on thetarget:

If both of these conditions are met, your application will not behave asexpected. The reason for this misbehavior is because thedevtool deploy-target command does not deploy the packages (e.g.libraries) on which your new application depends. The assumption is thatthe packages are already on the target. Consequently, when a runtimecall is made in the application for a dependent function (e.g. a librarycall), the function cannot be found.

Use the devtool search command to search for available targetrecipes. The command matches the recipe name, package name, description,and installed files. The command displays the recipe name as a result ofa match.

A Linux Foundation Collaborative Project.

All Rights Reserved. Linux Foundation and Yocto Project are registered trademarks of the Linux Foundation.

Linux is a registered trademark of Linus Torvalds.

Copyright 2010-2024, The Linux Foundation, CC-BY-SA-2.0-UK license

Last updated on Jul 24, 2024 from the yocto-docs git repository.

3a8082e126