In yocto recipe, we can use FIlE to assign which file or directory will be existed. ( this is my understanding )
What would happen if don’t assign FILE?
Ex:
FILES_${PN} += "/usr/local/bin/foo.sh"
do_install_append () {
install -m 755 -d ${D}/usr/local/bin
install -m 555 ${S}/foo.sh ${D}/usr/local/bin/
}
FILES_<packagename> variables define what files will be included in the package (${PN} refers to the recipes main package). The variables have default values (see meta/conf/bitbake.conf). These default values can be changed by your recipe or a class it inherits. You can check the final values with bitbake -e <recipe>|grep ^FILES_.
If your recipe installs files that are not included in the final FILES_* values, bitbake will complain.
Related
I have two recipes, a.bb & b.bb. Now in a.bb do_install, I am creating a sample.txt file and placing it under ${S} of "a" (or if needed can be placed under ${D}. Now when b.bb executes, in its do_install, I need to access the sample.txt
a.bb
do_install () {
echo "sample" > ${S}/sample.txt
}
b.bb
do_install () {
//access sample.txt here
}
I have set DEPENDS such that a.bb will be executed before b.bb.. now any pointer to achieve the above scenario? in yocto manual I see references of STAGING_DIR*, but did not find any helpful example.
You can't access (reliably) temporary files from another package. Each package is built independently in its own "sandbox". If files from one package are needed for other packages they need to be exported in the sysroot.
Please generate sample.txt to sysroot using ${D} during do_install and then you can access it from in the specific path in sysroot.
a.bb
do_install () {
echo "sample" > ${D}${includedir}/sample.txt
}
b.bb
do_install () {
// action example
install -m 0644 ${D}${includedir}/sample.txt ${S}/sample_2.txt
}
The ${D} variable allows the software being built to be installed in a directory other than its real target.
It Depends on what you want to do. If you want to use header or library files from recipe a.bb, then you should add corresponding package of recipe a.bb to DEPENDS in b.bb. Now b.bb will automatically look for files from SYSROOT during compilation/installation.
Or if you just want to add some file/changes to source, then create .patch for change and add to SRC_URI in both the recipe's
a.bb
SRC_URI += "file://sample.patch"
b.bb
SRC_URI += "file://sample.patch"
I have a makefile, ImpTarget.mk, defined with following content, taken from this example:
%.h: %.dummy_force
#echo header= $# xyz
%.dummy_force: ;
I include this file in the MAKEFILES variable
This is my top-level makefile (modified with the MAKEFILES variable)
MAKEFILES = "C:\Users\User1\Desktop\A\ImpTarget.mk"
all:
$(MAKE) -C src -f makefile_gen all
$(MAKE) -C src DEBUG=TRUE -f makefile_gen all
My goal is to turn all files - .h, .cpp, etc - in the prerequisites list into targets also i.e., executing make --print-database should yield a statement that every header file is also a target.
However, it's not working.
When I look at the database printed out, for each makefile I see that MAKEFILES is equal to "C:\Users\User1\Desktop\A\ImpTarget.mk" which is good because it means that it should be reading in ImpTarget.mk
3.4 The Variable MAKEFILES
If the environment variable MAKEFILES is defined, make considers its
value as a list of names (separated by whitespace) of additional
makefiles to be read before the others.
But it is not turning each file into a target. I still get:
# Not a target:
C:/Users/User1/Desktop/A/HMI_FORGF/qt5binaries/include/QtCore/qglobalstatic.h:
# Implicit rule search has been done.
# Last modified 2016-05-12 10:10:13
# File has been updated.
# Successfully updated.
In fact, the rule I defined is not even showing up in the --print-data-base part of the output.
I put the xyz as a marker so I could easily locate it in the listing of the rules that are executed but it doesn't appear in that list.
Why not use include?
Well first of all, what's the difference? Show me a link.
Secondly, yes that's the preferred method but some of my makefiles auto-generate a makefile, then inside that one generate another makefile and execute it.
So I don't have control over my build system enough to do that.
If the environment variable MAKEFILES is defined
Meaning make will only consider MAKEFILES if it is defined externally to make, either in the shell environment itself or by running make MAKEFILES=foo.mk.
MAKEFILES vs include is explained in the next paragraph
The main use of MAKEFILES is in communication between recursive invocations of make
You need to export the MAKEFILE variable into the environment. From 6.10 Variables from the Environment
When make runs a recipe, variables defined in the makefile are placed into the environment of each shell. This allows you to pass values to sub-make invocations (see Recursive Use of make). By default, only variables that came from the environment or the command line are passed to recursive invocations. You can use the export directive to pass other variables. See Communicating Variables to a Sub-make, for full details.
Since MAKEFILES wasn't found in the original environment, it isn't automatically passed into the environment. Use:
export MAKEFILES = "C:\Users\User1\Desktop\A\ImpTarget.mk"
I'll try to explain it as easy as I can. I tried to include and build package "A" in my Yocto image, but package A depends on libftdi and ftdi-eeprom. Now, "ftdi-eeprom" depends on the "libftdi".
In the newer versions of the "libftdi" the tarball also includes the ftdi-eeprom sources too and when you build the libftdi it builds both of the packages. Although because of the way that package "A" is configured I need two different recipes for each of the dependencies.
long story short, I made the two bitbake recipes as best as I could and successfully built "libftdi". Now when I run the "ftdi-eeprom" recipe, it wants to populate some files into the sysroot that are already installed there by libftdi. Here is where the error occurs... duplicates!
Apparently I need to set a SSTATE_DUPWHITELIST variable and declare that these duplicate files are safe to replace the old ones in the image (this overwrite must happen). Can someone please help me with configuring the SSTATE_DUPWHITELIST? I am not that pro working with Yocto.
Errors that I get on screen are uploaded in Dropbox
Thanks in advance!
The answer is to not use SSTATE_DUPWHITELIST for this at all. Instead, in the libftdi recipe's do_install (or do_install_append, if the recipe itself doesn't define its own do_install) you should delete the duplicate files from within ${D} and then they won't get staged and the error won't occur.
I got it to work by using:
SSTATE_DUPWHITELIST = "/"
Dont forget the quotes. Here's my bb excerpt:
SSTATE_DUPWHITELIST = "/"
DEPENDS = ""
do_unpack() {
mkdir -pv ${S}
tar xvf ${DL_DIR}/${FILENAME}.tar -C ${S}
}
do_install() {
install -d -m 755 ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader1.h ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader2.h ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader3.h ${D}${includedir}
}
I managed to solve this problem by adding the SSTATE_DUPWHITELIST to the bitbake recipe of the package as follows:
SSTATE_DUPWHITELIST = "${TMPDIR}/PATH/TO/THE/FILES"
I added the absolute path of all of the 6,7 files that had the conflict to the list. I did that because they were basically coming from a same source and it was all safe to do that. correct me if there is a better way though.
Hope this helps someone!
I installed/ miniconda in the following directory:
/home/arturo/Documents/project1/pwd
but then I deleted it by typing:
rm -r pwd/
Now I can't run python anymore (from any directory). Not really sure what happened. I get this error:
bash: /home/arturo/Documents/project1/pwd/bin/python: No such file or directory
You have at least two choices:
Reinstall miniconda, into the same location as before.
Clear the executable cache with hash -r to eliminate the stale entry, which ties the python command to non-existent /home/arturo/Documents/project1/pwd/bin/python cf. What is the purpose of the hash command?
I'm working on a github repo which I just cloned. I have a new virtual environment and I'd like to add all of the packages from the requirements.txt file to the virtual env.
For some reason it is not finding my requirements.txt file.
Edit the first line of /Users/byrd/Desktop/Github Repositories/herokusite/venv/bin/pip file to correct the path to python. You can obtain this path by calling which python. I think it should be:
#!/Users/byrd/Desktop/Github\ Repositories/herokusite/venv/bin/python
EDIT: Seems like it is a known bug in unixes - you can't use spaces in shebang line.
Also try this workaround, it may help you.
Do not use spaces in any component of the path where your virtual environment is stored.
It causes problems for the bootstrapping process.
Create a new blank environment, in a directory that has no spaces in its path:
$ cd # this takes you to your home directory, in OSX its is /Users/yourlogin
$ cd Desktop
$ virtualenv myvenv
$ source myvenv/bin/activate
(myvenv) $ pip install -r /path/to/requirements.txt
first, execute which pip after activating the environment if you found a space between any of the folders like
as seen in this link
you must have noticed a space between the folder name
2nd july
next, delete the new virualenv (in my case envname) and rename the folder with space between its name
then create a new virual environment and then install the requirements through
pip install -r requirements.txt
on the folder location with the requirements file