1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3***************************
4``devtool`` Quick Reference
5***************************
6
7The ``devtool`` command-line tool provides a number of features that
8help you build, test, and package software. This command is available
9alongside the ``bitbake`` command. Additionally, the ``devtool`` command
10is a key part of the extensible SDK.
11
12This chapter provides a Quick Reference for the ``devtool`` command. For
13more information on how to apply the command when using the extensible
14SDK, see the ":doc:`/sdk-manual/extensible`" chapter in the Yocto
15Project Application Development and the Extensible Software Development
16Kit (eSDK) manual.
17
18.. _devtool-getting-help:
19
20Getting Help
21============
22
23The ``devtool`` command line is organized similarly to Git in that it
24has a number of sub-commands for each function. You can run
25``devtool --help`` to see all the commands::
26
27   $ devtool --help
28   NOTE: Starting bitbake server...
29   usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] <subcommand> ...
30
31   OpenEmbedded development tool
32
33   options:
34     --basepath BASEPATH   Base directory of SDK / build directory
35     --bbpath BBPATH       Explicitly specify the BBPATH, rather than getting it from the metadata
36     -d, --debug           Enable debug output
37     -q, --quiet           Print only errors
38     --color COLOR         Colorize output (where COLOR is auto, always, never)
39     -h, --help            show this help message and exit
40
41   subcommands:
42     Beginning work on a recipe:
43       add                   Add a new recipe
44       modify                Modify the source for an existing recipe
45       upgrade               Upgrade an existing recipe
46     Getting information:
47       status                Show workspace status
48       latest-version        Report the latest version of an existing recipe
49       check-upgrade-status  Report upgradability for multiple (or all) recipes
50       search                Search available recipes
51     Working on a recipe in the workspace:
52       build                 Build a recipe
53       ide-sdk               Setup the SDK and configure the IDE
54       rename                Rename a recipe file in the workspace
55       edit-recipe           Edit a recipe file
56       find-recipe           Find a recipe file
57       configure-help        Get help on configure script options
58       update-recipe         Apply changes from external source tree to recipe
59       reset                 Remove a recipe from your workspace
60       finish                Finish working on a recipe in your workspace
61     Testing changes on target:
62       deploy-target         Deploy recipe output files to live target machine
63       undeploy-target       Undeploy recipe output files in live target machine
64       build-image           Build image including workspace recipe packages
65     Advanced:
66       create-workspace      Set up workspace in an alternative location
67       import                Import exported tar archive into workspace
68       export                Export workspace into a tar archive
69       extract               Extract the source for an existing recipe
70       sync                  Synchronize the source tree for an existing recipe
71       menuconfig            Alter build-time configuration for a recipe
72   Use devtool <subcommand> --help to get help on a specific command
73
74As directed in the general help output, you can
75get more syntax on a specific command by providing the command name and
76using ``--help``::
77
78   $ devtool add --help
79   NOTE: Starting bitbake server...
80   usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI] [--npm-dev] [--no-pypi] [--version VERSION] [--no-git] [--srcrev SRCREV | --autorev]
81                      [--srcbranch SRCBRANCH] [--binary] [--also-native] [--src-subdir SUBDIR] [--mirrors] [--provides PROVIDES]
82                      [recipename] [srctree] [fetchuri]
83
84   Adds a new recipe to the workspace to build a specified source tree. Can optionally fetch a remote URI and unpack it to create the source tree.
85
86   arguments:
87     recipename            Name for new recipe to add (just name - no version, path or extension). If not specified, will attempt to auto-detect it.
88     srctree               Path to external source tree. If not specified, a subdirectory of /media/build1/poky/build/workspace/sources will be used.
89     fetchuri              Fetch the specified URI and extract it to create the source tree
90
91   options:
92     -h, --help            show this help message and exit
93     --same-dir, -s        Build in same directory as source
94     --no-same-dir         Force build in a separate build directory
95     --fetch URI, -f URI   Fetch the specified URI and extract it to create the source tree (deprecated - pass as positional argument instead)
96     --npm-dev             For npm, also fetch devDependencies
97     --no-pypi             Do not inherit pypi class
98     --version VERSION, -V VERSION
99                           Version to use within recipe (PV)
100     --no-git, -g          If fetching source, do not set up source tree as a git repository
101     --srcrev SRCREV, -S SRCREV
102                           Source revision to fetch if fetching from an SCM such as git (default latest)
103     --autorev, -a         When fetching from a git repository, set SRCREV in the recipe to a floating revision instead of fixed
104     --srcbranch SRCBRANCH, -B SRCBRANCH
105                           Branch in source repository if fetching from an SCM such as git (default master)
106     --binary, -b          Treat the source tree as something that should be installed verbatim (no compilation, same directory structure). Useful with binary packages e.g. RPMs.
107     --also-native         Also add native variant (i.e. support building recipe for the build host as well as the target machine)
108     --src-subdir SUBDIR   Specify subdirectory within source tree to use
109     --mirrors             Enable PREMIRRORS and MIRRORS for source tree fetching (disable by default).
110     --provides PROVIDES, -p PROVIDES
111                           Specify an alias for the item provided by the recipe. E.g. virtual/libgl
112
113.. _devtool-the-workspace-layer-structure:
114
115The Workspace Layer Structure
116=============================
117
118``devtool`` uses a "Workspace" layer in which to accomplish builds. This
119layer is not specific to any single ``devtool`` command but is rather a
120common working area used across the tool.
121
122The following figure shows the workspace structure:
123
124.. image:: figures/build-workspace-directory.png
125   :scale: 100%
126
127.. code-block:: none
128
129   attic - A directory created if devtool believes it must preserve
130           anything when you run "devtool reset".  For example, if you
131           run "devtool add", make changes to the recipe, and then
132           run "devtool reset", devtool takes notice that the file has
133           been changed and moves it into the attic should you still
134           want the recipe.
135
136   README - Provides information on what is in workspace layer and how to
137            manage it.
138
139   .devtool_md5 - A checksum file used by devtool.
140
141   appends - A directory that contains *.bbappend files, which point to
142             external source.
143
144   conf - A configuration directory that contains the layer.conf file.
145
146   recipes - A directory containing recipes.  This directory contains a
147             folder for each directory added whose name matches that of the
148             added recipe.  devtool places the recipe.bb file
149             within that sub-directory.
150
151   sources - A directory containing a working copy of the source files used
152             when building the recipe.  This is the default directory used
153             as the location of the source tree when you do not provide a
154             source tree path.  This directory contains a folder for each
155             set of source files matched to a corresponding recipe.
156
157.. _devtool-adding-a-new-recipe-to-the-workspace:
158
159Adding a New Recipe to the Workspace Layer
160==========================================
161
162Use the ``devtool add`` command to add a new recipe to the workspace
163layer. The recipe you add should not exist --- ``devtool`` creates it for
164you. The source files the recipe uses should exist in an external area.
165
166The following example creates and adds a new recipe named ``jackson`` to
167a workspace layer the tool creates. The source code built by the recipes
168resides in ``/home/user/sources/jackson``::
169
170   $ devtool add jackson /home/user/sources/jackson
171
172If you add a recipe and the workspace layer does not exist, the command
173creates the layer and populates it as described in
174":ref:`devtool-the-workspace-layer-structure`" section.
175
176Running ``devtool add`` when the workspace layer exists causes the tool
177to add the recipe, append files, and source files into the existing
178workspace layer. The ``.bbappend`` file is created to point to the
179external source tree.
180
181.. note::
182
183   If your recipe has runtime dependencies defined, you must be sure
184   that these packages exist on the target hardware before attempting to
185   run your application. If dependent packages (e.g. libraries) do not
186   exist on the target, your application, when run, will fail to find
187   those functions. For more information, see the
188   ":ref:`ref-manual/devtool-reference:deploying your software on the target machine`"
189   section.
190
191By default, ``devtool add`` uses the latest revision (i.e. master) when
192unpacking files from a remote URI. In some cases, you might want to
193specify a source revision by branch, tag, or commit hash. You can
194specify these options when using the ``devtool add`` command:
195
196-  To specify a source branch, use the ``--srcbranch`` option::
197
198      $ devtool add --srcbranch &DISTRO_NAME_NO_CAP; jackson /home/user/sources/jackson
199
200   In the previous example, you are checking out the &DISTRO_NAME_NO_CAP;
201   branch.
202
203-  To specify a specific tag or commit hash, use the ``--srcrev``
204   option::
205
206      $ devtool add --srcrev &DISTRO_REL_TAG; jackson /home/user/sources/jackson
207      $ devtool add --srcrev some_commit_hash /home/user/sources/jackson
208
209   The previous examples check out the
210   &DISTRO_REL_TAG; tag and the commit associated with the
211   some_commit_hash hash.
212
213.. note::
214
215   If you prefer to use the latest revision every time the recipe is
216   built, use the options ``--autorev`` or ``-a``.
217
218.. _devtool-extracting-the-source-for-an-existing-recipe:
219
220Extracting the Source for an Existing Recipe
221============================================
222
223Use the ``devtool extract`` command to extract the source for an
224existing recipe. When you use this command, you must supply the root
225name of the recipe (i.e. no version, paths, or extensions), and you must
226supply the directory to which you want the source extracted.
227
228Additional command options let you control the name of a development
229branch into which you can checkout the source and whether or not to keep
230a temporary directory, which is useful for debugging.
231
232.. _devtool-synchronizing-a-recipes-extracted-source-tree:
233
234Synchronizing a Recipe's Extracted Source Tree
235==============================================
236
237Use the ``devtool sync`` command to synchronize a previously extracted
238source tree for an existing recipe. When you use this command, you must
239supply the root name of the recipe (i.e. no version, paths, or
240extensions), and you must supply the directory to which you want the
241source extracted.
242
243Additional command options let you control the name of a development
244branch into which you can checkout the source and whether or not to keep
245a temporary directory, which is useful for debugging.
246
247.. _devtool-modifying-a-recipe:
248
249Modifying an Existing Recipe
250============================
251
252Use the ``devtool modify`` command to begin modifying the source of an
253existing recipe. This command is very similar to the
254:ref:`add <devtool-adding-a-new-recipe-to-the-workspace>` command
255except that it does not physically create the recipe in the workspace
256layer because the recipe already exists in an another layer.
257
258The ``devtool modify`` command extracts the source for a recipe, sets it
259up as a Git repository if the source had not already been fetched from
260Git, checks out a branch for development, and applies any patches from
261the recipe as commits on top. You can use the following command to
262checkout the source files::
263
264   $ devtool modify recipe
265
266Using the above command form, ``devtool`` uses the existing recipe's
267:term:`SRC_URI` statement to locate the upstream source,
268extracts the source into the default sources location in the workspace.
269The default development branch used is "devtool".
270
271.. _devtool-edit-an-existing-recipe:
272
273Edit an Existing Recipe
274=======================
275
276Use the ``devtool edit-recipe`` command to run the default editor, which
277is identified using the ``EDITOR`` variable, on the specified recipe.
278
279When you use the ``devtool edit-recipe`` command, you must supply the
280root name of the recipe (i.e. no version, paths, or extensions). Also,
281the recipe file itself must reside in the workspace as a result of the
282``devtool add`` or ``devtool upgrade`` commands.
283
284.. _devtool-updating-a-recipe:
285
286Updating a Recipe
287=================
288
289Use the ``devtool update-recipe`` command to update your recipe with
290patches that reflect changes you make to the source files. For example,
291if you know you are going to work on some code, you could first use the
292:ref:`devtool modify <devtool-modifying-a-recipe>` command to extract
293the code and set up the workspace. After which, you could modify,
294compile, and test the code.
295
296When you are satisfied with the results and you have committed your
297changes to the Git repository, you can then run the
298``devtool update-recipe`` to create the patches and update the recipe::
299
300   $ devtool update-recipe recipe
301
302If you run the ``devtool update-recipe``
303without committing your changes, the command ignores the changes.
304
305Often, you might want to apply customizations made to your software in
306your own layer rather than apply them to the original recipe. If so, you
307can use the ``-a`` or ``--append`` option with the
308``devtool update-recipe`` command. These options allow you to specify
309the layer into which to write an append file::
310
311   $ devtool update-recipe recipe -a base-layer-directory
312
313The ``*.bbappend`` file is created at the
314appropriate path within the specified layer directory, which may or may
315not be in your ``bblayers.conf`` file. If an append file already exists,
316the command updates it appropriately.
317
318.. _devtool-checking-on-the-upgrade-status-of-a-recipe:
319
320Checking on the Upgrade Status of a Recipe
321==========================================
322
323Upstream recipes change over time. Consequently, you might find that you
324need to determine if you can upgrade a recipe to a newer version.
325
326To check on the upgrade status of a recipe, you can use the
327``devtool latest-version recipe`` command, which quickly shows the current
328version and the latest version available upstream. To get a more global
329picture, use the ``devtool check-upgrade-status`` command, which takes a
330list of recipes as input, or no arguments, in which case it checks all
331available recipes. This command will only print the recipes for which
332a new upstream version is available. Each such recipe will have its current
333version and latest upstream version, as well as the email of the maintainer
334and any additional information such as the commit hash or reason for not
335being able to upgrade it, displayed in a table.
336
337This upgrade checking mechanism relies on the optional :term:`UPSTREAM_CHECK_URI`,
338:term:`UPSTREAM_CHECK_REGEX`, :term:`UPSTREAM_CHECK_GITTAGREGEX`,
339:term:`UPSTREAM_CHECK_COMMITS` and :term:`UPSTREAM_VERSION_UNKNOWN`
340variables in package recipes.
341
342.. note::
343
344   -  Most of the time, the above variables are unnecessary. They are only
345      required when upstream does something unusual, and default
346      mechanisms cannot find the new upstream versions.
347
348   -  For the ``oe-core`` layer, recipe maintainers come from the
349      :yocto_git:`maintainers.inc </poky/tree/meta/conf/distro/include/maintainers.inc>`
350      file.
351
352   -  If the recipe is using the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:git fetcher (\`\`git://\`\`)`
353      rather than a tarball, the commit hash points to the commit that matches
354      the recipe's latest version tag, or in the absence of suitable tags,
355      to the latest commit (when :term:`UPSTREAM_CHECK_COMMITS` set to ``1``
356      in the recipe).
357
358As with all ``devtool`` commands, you can get help on the individual
359command::
360
361   $ devtool check-upgrade-status -h
362   NOTE: Starting bitbake server...
363   usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]]
364
365   Prints a table of recipes together with versions currently provided by recipes, and latest upstream versions, when there is a later version available
366
367   arguments:
368     recipe      Name of the recipe to report (omit to report upgrade info for all recipes)
369
370   options:
371     -h, --help  show this help message and exit
372     --all, -a   Show all recipes, not just recipes needing upgrade
373
374Unless you provide a specific recipe name on the command line, the
375command checks all recipes in all configured layers.
376
377Here is a partial example table that reports on all the recipes::
378
379   $ devtool check-upgrade-status
380   ...
381   INFO: bind                      9.16.20         9.16.21         Armin Kuster <akuster808@gmail.com>
382   INFO: inetutils                 2.1             2.2             Tom Rini <trini@konsulko.com>
383   INFO: iproute2                  5.13.0          5.14.0          Changhyeok Bae <changhyeok.bae@gmail.com>
384   INFO: openssl                   1.1.1l          3.0.0           Alexander Kanavin <alex.kanavin@gmail.com>
385   INFO: base-passwd               3.5.29          3.5.51          Anuj Mittal <anuj.mittal@intel.com>  cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility
386   ...
387
388Notice the reported reason for not upgrading the ``base-passwd`` recipe.
389In this example, while a new version is available upstream, you do not
390want to use it because the dependency on ``cdebconf`` is not easily
391satisfied. Maintainers can explicit the reason that is shown by adding
392the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe.
393See :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb?h=kirkstone>`
394for an example::
395
396   RECIPE_NO_UPDATE_REASON = "Version 3.5.38 requires cdebconf for update-passwd utility"
397
398Last but not least, you may set :term:`UPSTREAM_VERSION_UNKNOWN` to ``1``
399in a recipe when there's currently no way to determine its latest upstream
400version.
401
402.. _devtool-upgrading-a-recipe:
403
404Upgrading a Recipe
405==================
406
407As software matures, upstream recipes are upgraded to newer versions. As
408a developer, you need to keep your local recipes up-to-date with the
409upstream version releases. There are several ways of upgrading recipes.
410You can read about them in the ":ref:`dev-manual/upgrading-recipes:upgrading recipes`"
411section of the Yocto Project Development Tasks Manual. This section
412overviews the ``devtool upgrade`` command.
413
414Before you upgrade a recipe, you can check on its upgrade status. See
415the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`" section
416for more information.
417
418The ``devtool upgrade`` command upgrades an existing recipe to a more
419recent version of the recipe upstream. The command puts the upgraded
420recipe file along with any associated files into a "workspace" and, if
421necessary, extracts the source tree to a specified location. During the
422upgrade, patches associated with the recipe are rebased or added as
423needed.
424
425When you use the ``devtool upgrade`` command, you must supply the root
426name of the recipe (i.e. no version, paths, or extensions), and you must
427supply the directory to which you want the source extracted. Additional
428command options let you control things such as the version number to
429which you want to upgrade (i.e. the :term:`PV`), the source
430revision to which you want to upgrade (i.e. the
431:term:`SRCREV`), whether or not to apply patches, and so
432forth.
433
434You can read more on the ``devtool upgrade`` workflow in the
435":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
436section in the Yocto Project Application Development and the Extensible
437Software Development Kit (eSDK) manual. You can also see an example of
438how to use ``devtool upgrade`` in the ":ref:`dev-manual/upgrading-recipes:using \`\`devtool upgrade\`\``"
439section in the Yocto Project Development Tasks Manual.
440
441.. _devtool-resetting-a-recipe:
442
443Resetting a Recipe
444==================
445
446Use the ``devtool reset`` command to remove a recipe and its
447configuration (e.g. the corresponding ``.bbappend`` file) from the
448workspace layer. Realize that this command deletes the recipe and the
449append file. The command does not physically move them for you.
450Consequently, you must be sure to physically relocate your updated
451recipe and the append file outside of the workspace layer before running
452the ``devtool reset`` command.
453
454If the ``devtool reset`` command detects that the recipe or the append
455files have been modified, the command preserves the modified files in a
456separate "attic" subdirectory under the workspace layer.
457
458Here is an example that resets the workspace directory that contains the
459``mtr`` recipe::
460
461   $ devtool reset mtr
462   NOTE: Cleaning sysroot for recipe mtr...
463   NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually
464   $
465
466.. _devtool-finish-working-on-a-recipe:
467
468Finish Working on a Recipe
469==========================
470
471Use the ``devtool finish`` command to push any committed changes to the
472specified recipe in the specified layer and remove it from your workspace.
473
474This is roughly equivalent to the ``devtool update-recipe`` command followed by
475the ``devtool reset`` command. The changes must have been committed to the git
476repository created by ``devtool``. Here is an example::
477
478  $ devtool finish recipe /path/to/custom/layer
479
480.. _devtool-building-your-recipe:
481
482Building Your Recipe
483====================
484
485Use the ``devtool build`` command to build your recipe. The
486``devtool build`` command is equivalent to the
487``bitbake -c populate_sysroot`` command.
488
489When you use the ``devtool build`` command, you must supply the root
490name of the recipe (i.e. do not provide versions, paths, or extensions).
491You can use either the ``-s`` or the ``--disable-parallel-make`` options to
492disable parallel makes during the build. Here is an example::
493
494   $ devtool build recipe
495
496.. _devtool-building-your-image:
497
498Building Your Image
499===================
500
501Use the ``devtool build-image`` command to build an image, extending it
502to include packages from recipes in the workspace. Using this command is
503useful when you want an image that ready for immediate deployment onto a
504device for testing. For proper integration into a final image, you need
505to edit your custom image recipe appropriately.
506
507When you use the ``devtool build-image`` command, you must supply the
508name of the image. This command has no command line options::
509
510   $ devtool build-image image
511
512.. _devtool-deploying-your-software-on-the-target-machine:
513
514Deploying Your Software on the Target Machine
515=============================================
516
517Use the ``devtool deploy-target`` command to deploy the recipe's build
518output to the live target machine::
519
520   $ devtool deploy-target recipe target
521
522The target is the address of the target machine, which must be running
523an SSH server (i.e. ``user@hostname[:destdir]``).
524
525This command deploys all files installed during the
526:ref:`ref-tasks-install` task. Furthermore, you do not
527need to have package management enabled within the target machine. If
528you do, the package manager is bypassed.
529
530.. note::
531
532   The ``deploy-target`` functionality is for development only. You
533   should never use it to update an image that will be used in
534   production.
535
536Some conditions could prevent a deployed application from
537behaving as expected. When both of the following conditions are met, your
538application has the potential to not behave correctly when run on the
539target:
540
541-  You are deploying a new application to the target and the recipe you
542   used to build the application had correctly defined runtime
543   dependencies.
544
545-  The target does not physically have the packages on which the
546   application depends installed.
547
548If both of these conditions are met, your application will not behave as
549expected. The reason for this misbehavior is because the
550``devtool deploy-target`` command does not deploy the packages (e.g.
551libraries) on which your new application depends. The assumption is that
552the packages are already on the target. Consequently, when a runtime
553call is made in the application for a dependent function (e.g. a library
554call), the function cannot be found.
555
556To be sure you have all the dependencies local to the target, you need
557to be sure that the packages are pre-deployed (installed) on the target
558before attempting to run your application.
559
560.. _devtool-removing-your-software-from-the-target-machine:
561
562Removing Your Software from the Target Machine
563==============================================
564
565Use the ``devtool undeploy-target`` command to remove deployed build
566output from the target machine. For the ``devtool undeploy-target``
567command to work, you must have previously used the
568":ref:`devtool deploy-target <ref-manual/devtool-reference:deploying your software on the target machine>`"
569command::
570
571   $ devtool undeploy-target recipe target
572
573The target is the
574address of the target machine, which must be running an SSH server (i.e.
575``user@hostname``).
576
577.. _devtool-creating-the-workspace:
578
579Creating the Workspace Layer in an Alternative Location
580=======================================================
581
582Use the ``devtool create-workspace`` command to create a new workspace
583layer in your :term:`Build Directory`. When you create a
584new workspace layer, it is populated with the ``README`` file and the
585``conf`` directory only.
586
587The following example creates a new workspace layer in your current
588working and by default names the workspace layer "workspace"::
589
590   $ devtool create-workspace
591
592You can create a workspace layer anywhere by supplying a pathname with
593the command. The following command creates a new workspace layer named
594"new-workspace"::
595
596   $ devtool create-workspace /home/scottrif/new-workspace
597
598.. _devtool-get-the-status-of-the-recipes-in-your-workspace:
599
600Get the Status of the Recipes in Your Workspace
601===============================================
602
603Use the ``devtool status`` command to list the recipes currently in your
604workspace. Information includes the paths to their respective external
605source trees.
606
607The ``devtool status`` command has no command-line options::
608
609   $ devtool status
610
611Here is sample output after using
612:ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>`
613to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory::
614
615   $ devtool status
616   mtr:/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)
617   $
618
619.. _devtool-search-for-available-target-recipes:
620
621Search for Available Target Recipes
622===================================
623
624Use the ``devtool search`` command to search for available target
625recipes. The command matches the recipe name, package name, description,
626and installed files. The command displays the recipe name as a result of
627a match.
628
629When you use the ``devtool search`` command, you must supply a keyword.
630The command uses the keyword when searching for a match.
631
632Alternatively, the ``devtool find-recipe`` command can be used to search for
633recipe files instead of recipe names. Likewise, you must supply a keyword.
634
635.. _devtool-get-the-configure-script-help:
636
637Get Information on Recipe Configuration Scripts
638===============================================
639
640Use the ``devtool configure-help`` command to get help on the configuration
641script options for a given recipe. You must supply the recipe name to the
642command. For example, it shows the output of ``./configure --help`` for
643:ref:`autotools <ref-classes-autotools>`-based recipes.
644
645The ``configure-help`` command will also display the configuration options
646currently in use, including the ones passed through the :term:`EXTRA_OECONF`
647variable.
648
649.. _devtool-generate-an-ide-configuration-for-a-recipe:
650
651Generate an IDE Configuration for a Recipe
652==========================================
653
654The ``devtool ide-sdk`` automatically creates an IDE configuration and SDK to
655work on a given recipe. Depending on the ``--mode`` parameter, different types
656of SDKs are generated:
657
658-  ``modified`` mode: this creates an SDK and generates an IDE configuration in
659   the workspace directory.
660
661-  ``shared`` mode: this creates a cross-compiling toolchain and the
662   corresponding shared sysroot directories of the supplied recipe(s).
663
664The ``--target`` option can be used to specify a ``username@hostname`` string
665and create a remote debugging configuration for the recipe. Similarly to
666``devtool deploy-target``, it requires an SSH server running on the target.
667
668For further details on the ``devtool ide-sdk`` command, see the
669":doc:`/sdk-manual/extensible`" chapter in the Yocto Project Application
670Development and the Extensible Software Development Kit (eSDK) manual.
671