I'm a beginner of Yocto project.
So, I'm really hope to know how to build *.bb files which I added.
I am added a .bb file (dlt-daemon) to meta-/meta-*/recipes-expends/dlt-daemon/dlt-daemon_v2.14.1.bb.
However, whenever I try to build it (bitbake core-image-weston) it isn't built.
I tried to build a *.bb file only ( bitbake -b ******/*.bb -c compile ) but there is no output file in the rootfs. ( I found the output files at build/tmp/work/arch****/dlt-daemon/2.14.1-r0/build/***** )
I'm not sure why it doesn't work?
Please, can I know how to build *.bb files which I added?
Preferably, you should add your own recipes in your own layer.
But nevertheless, just adding a recipe (ie .bb-file) won't add it to any rootfs. If you can run
bitbake your-recipe
without getting any errors, your recipe is working as it should (there could still be some issues if you're not installing any files etc). You can confirm that it's working by either looking at the logs for the different tasks (in ${WORKDIR}/<arch>/recipe-name/recipe-version/temp/).
Still being able to build your recipe isn't enough for what you want. For the application in question to appear in you rootfs, you need to add it to your image. Temporarily, you can add the following line to your conf/local.conf:
IMAGE_INSTALL_append = " <package-name>"
Note the leading space. To make it permanent, you should add the <package-name> to IMAGE_INSTALL directly in you image recipe.
Open your local.conf file and add below line e.g: hello.bb
IMAGE_INSTALL_append = " hello" # "space" before hello. this will add to your rfs image
Then compile your rfs using bitbake core-image-minimal
Related
I have recently started using Yocto. I 'm looking for option to include/add altered package into final build image. Below I have described the scenario.
I'm working on RDK, which is yocto based system for STB(Set-top Box) Emulator. I have already build complete system once. Now I'm making some changes in some particular module, to see final effect of that in build/image, I rebuilt that particular module(at this point I came to know bitbake doesn't work like makefile utility, that you make changes and it will take care of rest and your package will be compiled as well as included into final image/binary), I used bitbake -c cleansstate <module_name>, then bitbake <module_name> to rebuild the package.
Next thing was to get it inside the final image, but the same thing I had to go through the pain again, bitbake -c cleansstate <image_name>, then bitbake <image_name> to rebuild the image.
Basically, only once package is changed and to include that into final image I have create complete image again.Which is very time-consuming process!!!
I'm wondering is there any way that I can reduce this build time and include altered package into final image?
NOTE: Not looking for optimization option, I know about local.conf BB_NUMBER_THREADS and PARALLEL_MAKE options. It is just about, can we add package into final image without generating all dependency for final image as described in scenario.
Assuming by "making changes" you mean modifying the underlying code, I would suggest using devtool modify - this will set up a local source tree for the recipe where you can make your changes, and each time you make a change and then run bitbake on the recipe or something that depends upon it (such as your image) it will rebuild it including your changes. Basic steps:
devtool modify <recipe>
Make your changes within the source tree that is set up
bitbake <recipe> or bitbake <image>
Test the result; loop back to step 2 if you need to make further changes
devtool finish <recipe> to write your changes back as patches against the recipe
I happened to me that after adding a recipe on meta/recipes-extended/myrecipe_0.0.1.bb
I was able to build my new recipe with the command
bitbake myrecipe
but the binaries never got included on the rootfs image when running
bitbake core-image-minimal
To add the output of my recipe to the output images, I've added the following to my ${BUILDDIR}/conf/local.conf file:
IMAGE_INSTALL_append = " myrecipe"
in my local.conf file.
I would like to edit an existing software to add a new source file (Source.cpp).
But, I can't manage the compilation process (it seems to be automake and it looks very complicated).
The software (iperf 2: https://sourceforge.net/projects/iperf2/files/?source=navbar) is compiled using a classical ./configure make then make install.
If I just add the file to the corresponding source and include directory, I got this error message:
Settings.cpp:(.text+0x969) : undefined reference to ...
It looks like the makefile isn't able to produce the output file associated with my new source file (Source.cpp). So, I probably need to indicate it manually somewhere.
I searched a bit in the project files and it seemed that the file to edit was: "Makefile.am".
I added my source to the variable iperf_SOURCES in that file but it didn't workded.
Could you help me to find the file where I need to indicate my new source file (it seems a pretty standard compilation scheme but I never used automake softwares and this one seems very complicated).
Thank you in advance
This project is built with the autotools, as you already figured out.
The makefiles are built by automake. It takes its input in files that usually have a am file name extension.
The iperf program is built by the makefile generated from src/Makefile.am. This is indicated by:
bin_PROGRAMS = iperf
All (actually this is a simplification, but which holds in this case) source files of a to be built binary are in the corresponding name_SOURCES variable, thus in this case iperf_SOURCES. Just add your source file to the end of that list, like so (keeping their formatting):
iperf_SOURCES = \
Client.cpp \
# lines omitted
tcp_window_size.c \
my_new_file.c
Now, to reflect this change in any future generated src/Makefile you need to run automake. This will modify src/Makefile.in, which is a template that is used by config.sub at the end of configure to generate the actual makefile.
Running automake can happen in various ways:
If you already have makefiles that were generated after an configure these should take care of rebuilding themselves. This seems to fail sometimes though!
You could run automake (in the top level directory) by hand. I've never done this, as there is the better solution to...
Run autoreconf --install (possibly add --force to the arguments) in the top level directory. This will regenerate the entire build system, calling all needed programs such as autoheader, autoconf and of course automake. This is my favorite solution.
The later two options require calling configure again, IMO ideally doing an out of source built:
# in top level dir
mkdir build
cd build
../configure # arguments
make # should now also compile and link your new source file
I have a project which is using yocto for building libraries including gstreamer. I found out that I need to patch some gstreamer element thus creating new bitbake recipe with patch..
I usually have to run bitbake with image name as parameter which will rebuild whole yocto (which is quite long):
MACHINE=some_machine nice bitbake yocto-etc-etc
How do I rebuild just that part which I need and not whole yocto?
I heard about devtool, but I am not sure how to use that.
you can pass different command to bitbake based on what you need.
To remove temp:
bitbake -c clean gstreamer
To remove temp and sstate cache (I use this most):
bitbake -c cleansstate gstreamer
To remove download as well, and lets begin build starting from do_fetch and all
bitbake -c cleanall gstreamer
Once you are done with either of these clean, which ever suits you, you can simple give build command for the specified:
bitbake gstreamer
Certainly, this is easy to do. Just specify the recipe you want to build instead of the image name, for example if it was the main gstreamer recipe you had changed (which at least in current versions is called gstreamer1.0):
MACHINE=some-machine bitbake gstreamer1.0
Note that the name expected on the command line is always a recipe name or something from PROVIDES in a recipe, and not a runtime package name.
Regarding devtool, it can certainly put you into an environment where you can more easily make changes to the source for a recipe and generate patches from them, but the actual building part we are discussing here doesn't really change. You can find more information on how to use devtool in the Yocto Project Development Manual
You can also
clean: Removes all output files for a target
cleanall: Removes all output files, shared state cache, and downloaded source files for a target, depending on the changes
bitbake -c clean task
bitbake -c cleanall task
First you can create a patch on the gstreamer using quilt or diff etc...
Put the patch into your meta layer and include it into,SRC_URI += "file://xxxx.patch".
Make sure you have added FILESEXTRAPATHS_PREPEND variable in the bbappend file of recipe.
Then do a cleansstate of the package.
bitabake gstreamer** -c cleansstate
Then execute do_patch operation and check our patch has been applied properly.
bitabake gstreamer*** -c patch
Then do the full build of the component followed by built the final target.
You can also launch the taskes you are interested in, for example:
If you want to apply only the patch you can do something like:
# Apply the patch you have located and sourced in SRC_URI variable previously
MACHINE=some_machine nice bitbake -c patch gstreamer
# Compile the recipe
MACHINE=some_machine nice bitbake -c compile gstreamer
# In case there are more necessary tasks, launch them as previous
Now you can get the generated package, and pass it to your board (eg. via ssh/serial(zmodem) ), test it and repeat until you like the resul, then regenerate the image doing:
for i in clean cleanall cleansstate;do bitbake -c ${i} gstreamer;done
MACHINE=some_machine nice bitbake yocto-etc-etc
you can build any specific recipe by providing the recipe name along with the bitbake command
For instance, If you want to build gstreamer
poky/meta/recipes-multimedia/gstreamer1.0_1.16.3.bb
you can use the following command
MACHINE=<your-machine-name> bitbake gstreamer1.0
Note that the PROVIDES value will be parsed from .bb filename excluding the characters after underscore.
Additional suggestions
If you want to do some experimental changes in your source and wants to compile for each minimalistic change, you could do that by navigating to
work directory
cd build/tmp/work/armv5e-poky-linux-gnueabi/gstreamer1.0/1.16.3-r0/
here you can apply your changes in src directory and you can use ./temp/run.do_compile to compile, which will take very less time compared to the entire build time.
I am using CLion (C++ IDE) for editing a ROS package. I was able to open a package by opening the CMakeLists.txt file. But, I get an error,
"FATAL_ERROR "find_package(catkin) failed. catkin was neither found in the workspace nor in the CMAKE_PREFIX_PATH. One reason may be that
no ROS setup.sh was sourced before"
How do I solve this problem? Will I be able to make the project in CLion (If so, how do I) after I make changes to the code or do I have to catkin_make in a separate terminal?
Try this (for Linux):
Open a command line
Run catkin_make on your package.
source your catkin_workspace/devel/setup.bash file e.g. source ~/my_dev_folder/catkin_ws/devel/setup.bash
Start CLion from [CLion install dir]/bin/clion.sh e.g. cd ~/Downloads/clion-1.2.4/bin && ./clion.sh
CLion should then start with knowledge about the packages in your catkin workspace, through the local environment variables set up by the setup.bash file.
To add on to what WillC suggested, you can also modify the desktop entry to start the application from bash instead of manually doing so.
To do this, edit the desktop file located at
~/.local/share/applications/jetbrains-clion.desktop
by modifying the line containing Exec= to
Exec=bash -i -c "/INSTALL_LOCATION/clion-2016.3.2/bin/clion.sh" %f
To add on to what WillC suggested,CLion reload the last cmake compiling result by default.
However, if you failed to find catkin.cmake during the last attempt even though you source the devel/setup.bash and open CLion, you also cannot find catkin.cmake.
You should click File --> Reload Cmake Project and you should get the right result.
I am looking for some documentation or tutorial for copying files from a given directory into the app created by xcode at build time, before it is run.
At first I have tried to copy files into the derived directory, hoping that everything resides in there would be automatically added to the app, but I was wrong.
So I am looking for a script because the original dir may change its name, second the script could be customized by another xcode 4 user with its src dir path etc.
The things is I don't know how to start, which language etc. I am quite confident with shell script, but maybe there's a better option.
Second, I am trying to figure out which command could add a file in the already built app.
thanks
That answer didn't really help - the BUILT_PRODUCT_DIR isn't where most stuff goes.
Ultimately, I found you just need to do:
Add the following to the very end of your script (or get your script to write directly to the output location):
cp ${DERIVED_FILE_DIR}/[YOUR OUTPUT FILES] ${BUILT_PRODUCTS_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}
...but there's a lot of other things I tried. More thoughts and ideas here: http://red-glasses.com/index.php/tutorials/xcode4-a-script-that-creates-adds-files-to-your-project/
You want a Run Script or Copy Files build phase. Select your main project in the navigator, then select the app's target. Click the Build Phases tab. Click the Add Build Phase button at the bottom of the window and choose the appropriate phase.
By "appropriate" I mean if you really want to run a script, you'll use a Run Script build phase and use Xcode-provided environment variables like $BUILT_PRODUCT_DIR (see the documentation or hit build and examine the full output of an empty script in the build log) to figure out your target folder. If all you want to do is copy files (no real processing), the Copy Files build phase already knows how to locate the app bundle's proper folders depending on what you're copying (Resources, Frameworks, etc.).