The only relevant and easy to understand example I found to use devtool in a Yocto Workflow was the Video from Tim Orling in Embedded Linux Conference
In his workflow:
He uses devtool add to add nano
devtool build to build it
devtool deploy-target to deploy it on qemu
devtool undeploy-target to remove nano
devtool finish nano ../meta-foo
I tried doing the same thing but there is no subcommand finish in devtool
when I try devtool finish --help
devtool finish --help
ERROR: argument <subcommand>: invalid choice: 'finish' (choose from 'create-workspace', 'add', 'modify', 'extract', 'sync', 'update-recipe', 'status', 'reset', 'build-image', 'deploy-target', 'undeploy-target', 'build', 'search', 'upgrade', 'edit-recipe', 'configure-help')
What is the equivalent subcommand for devtool finish. Is it devtool reset?
Build Host Environment
Ubuntu 16.04.4 LTS virtual machine
Bitbake version: 1.30.0
devtool information
usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q]
[--color COLOR] [-h]
<subcommand> ...
OpenEmbedded development tool
optional arguments:
--basepath BASEPATH Base directory of SDK / build directory
--bbpath BBPATH Explicitly specify the BBPATH, rather than getting it
from the metadata
-d, --debug Enable debug output
-q, --quiet Print only errors
--color COLOR Colorize output (where COLOR is auto, always, never)
-h, --help show this help message and exit
subcommands:
Beginning work on a recipe:
add Add a new recipe
modify Modify the source for an existing recipe
upgrade Upgrade an existing recipe
Getting information:
status Show workspace status
search Search available recipes
Working on a recipe in the workspace:
build Build a recipe
edit-recipe Edit a recipe file in your workspace
configure-help Get help on configure script options
update-recipe Apply changes from external source tree to recipe
reset Remove a recipe from your workspace
Testing changes on target:
deploy-target Deploy recipe output files to live target machine
undeploy-target Undeploy recipe output files in live target machine
build-image Build image including workspace recipe packages
Advanced:
create-workspace Set up workspace in an alternative location
extract Extract the source for an existing recipe
sync Synchronize the source tree for an existing recipe
Use devtool <subcommand> --help to get help on a specific command
Krogoth
for krogoth according to the Yocto 2.1.2 Development Manual devtool manual
The created recipes need to be manually placed into the custom meta-foo layer.
For other versions devtool finish recipe-name ../meta-foo should do it for you.
Related
I am setting up my yocto project, for that i have followed these below steps:
download the Poky Source code (ubuntu: /yocto/source)
$ git clone git://git.yoctoproject.org/poky
Checkout the latest branch/release (zeus)
$ git checkout zeus
Step 3: Prepare the build environment (ubuntu: /yocto/source/poky)
$ source oe-init-build-env ../../build
The above script will move in a build folder and create two files in conf folder ( local.conf, bblayers.conf ) inside conf folder
Building Linux Distribution (unbuntu: /yoctu/build)
$ bitbake core-image-minimal
Checking the runqemu (ubuntu: /yocto/source/poky/scripts)
$ ls runqemu // and it is there
Run generated image in qemu (ubuntu: /yocto/build)
$ runqemu qemux86-64 core-image-minimal
other window open for qemu and image runs well.
Problem
After using first time when i close the terminal, and use it again by running $ runqemu qemux86-64 core-image-minimal in (ubuntu: /yocto/build) error pops up runqemu: command not found and if i write bitbake in poky directory same error pops up bitbake: command not found.
NOTE: i have repeat this whole process 3 times to check if the installation is not correct but i have done everything fine from my side.
yocto project hierarchy:
If you close your poky environment terminal you always MUST re-source the environment.
The poky's oe-init-build-env setups up all commands for you, for instance:
runqemu* commands which are present in poky/scripts.
The script also export bitbake* commands from poky/bitbake/bin.
The line responsible for that is in:
poky/scripts/oe-buildenv-internal (line 99):
# Make sure our paths are at the beginning of $PATH
for newpath in "$BITBAKEDIR/bin" "$OEROOT/scripts"; do
# Remove any existences of $newpath from $PATH
PATH=$(echo $PATH | sed -re "s#(^|:)$newpath(:|$)#\2#g;s#^:##")
# Add $newpath to $PATH
PATH="$newpath:$PATH"
done
So, always if you open new terminal:
source /yocto/source/poky/oe-init-build-env /yoctu/build
EDIT
If you already have a build folder, make sure to provide the right path for that folder to the oe-init-build-env script.
If you provide new path to non-existing folder, than the script will create another build for you.
EDIT2
To source poky environment according to your path:
Relative:
cd ~/Documents/yocto/source/poky
source oe-init-build-env build
^
|
(because build is in same folder as the script)
Absolute:
source /home/$USER/Documents/yocto/source/poky/oe-init-build-env /home/$USER/Documents/yocto/source/poky/build
THE RULE
source <path/to/oe-init-build-env> <path/to/build/folder>
If <path/to/build/folder> exists then, poky will source the existing build environment.
If <path/to/build/folder> does not exist, poky will create new build under the same name and path.
I have downloaded an open source project from GitHub, I want to use Xcode open it can make changes.
but when I open it I get error, can not open file:
how to solve this issue?
You need to follow the instruction in the INSTAll file
Varnish uses the GNU autotools. To build and install Varnish, simply
run the 'configure' script in the top-level directory, then run 'make'
and 'make install'. On Linux, you need to run 'ldconfig' as root
afterwards in order to update the shared library cache.
If you obtained the sources directly from the Git repository, you will
need to run autogen.sh first to create the configure script.
Varnish will store run-time state in $localstatedir/varnish; you may
want to tune this using configure's --localstatedir parameter.
Additional configure options of interest:
--enable-developer-warnings
enable strict warnings (default is NO)
--enable-debugging-symbols
enable debugging symbols (default is NO)
I'm trying to debug my application on the target device. I'm using gdb-multiarch on the host and gdb-server on the target. Everything works fine with breakpoints and stepping.
My Problem is that my application is dependent on some of my on libs. When I step into a function of these libs the source code is not found. There is no /usr/src in my recipe-sysroot folder.
Steps I have done:
Generate eSDK: bitbake my-image -c populate_sdk_ext
Installed the eSDK to ~/my_sdk
devtool modify -n my-recipe ~/repositories/my-application
devtool build my-recipe
When I check the my-image.tar.gz generated by bitbake then I can find all the /usr/src folder. But the eSDK and devtool don't extract the files to the recipe-sysroot. How can I get this done? Is there an option I'm missing?
did you try to use devtool add to add the source ? in yocto the packages are usually debug free and source free, for example net-utils have net-util, netutil-dbg, net-util-dev and net-util-src.
I hit this error message while trying to build gnote using GNU Autotools.
I had first run:
$ git clean -xf # to clean the tree of untracked files, then
$ autoreconf # to create the script named `configure`, and finally
$ ./configure # to check my system, and create Makefiles from their templates
Neither po/Makefile.in.in nor po/Makefile.in exist in the source tree that I downloaded.
Yet configure needs to make this po/Makefile, as called for in the root Makefile.am in this line:
SUBDIRS = data src po help
Where do I get, or how do I make, po/Makefile.in.in?
Like all Gnome related packages, gnote uses many steps of buildsystem setup beyond just running autoreconf.
The autogen.sh script gnote comes with should run all the required steps to set up the buildsystem.
As usual, run the autogen.sh script with the --help parameter if you want to call configure separately.
po/Makefile.in.in is created by running intltoolize from the intltool package. It needs to be run from the project tree's root directory.
There isn't much documentation on intltoolize that I could find except for the brief man page, but it's source code says that that it's a fork of an older utility called libtoolize, and it's a relatively short script.
(BTW, if you don't already have intltoolize installed, you can figure out which package installs it, with this: sudo apt-file find intltoolize.)
*.in files are templates used by AutoMake to create a Makefile.
.in.in is a soft link to /usr/share/intltool/Makefile.in.in.
I use "devtool" of Yocto, eSDK to create the recipe.
I'd like to upgrade it the source code to build newer version package.
So I did update SRCREV and PV = "0.1+git${SRCPV}" variable but no different source tree is fetched (where SRCREV is pointing to).
I do following
devtool upgrade myrecipe --srcrev 82a02d8585d262d6ab2d9dc335ed2231dc2d7f06
I am getting error
ERROR: recipe is already in your workspace
How to correctly upgrade recipe with devtool (eSDK)?
Thanks for help.
Prior to this:
installed the extensible SDK
created generic recipe by
devtool add myrecipe "specified URI to fetch from"
run build command
devtool build myrecipe
deploy it to target
devtool deploy-target -s myrecipe root#192.168.15.241
after that the package is on target and everything seems OK.
Now I would need to upgrade recipe to the new version of software. I use devtool upgrade for that as described above and I have run into issue.
In a workflow starting with devtool add, devtool upgrade is not intended to be used. If you want to change to build a different revision in this context you would instead simply check it out in the repository (which would be under workspace/sources/myrecipe) using git checkout. When you later come to do devtool finish, devtool should update your recipe to check this revision out when building the recipe normally.