In bitbake disable downloading the module from repository every time i compiles the module. compile the module not download it everytime.
tried using noexec flag in the recipe but it didn't help.
Regards
Mayank
bitbake usually caches downloads in ${DL_DIR} (which defaults to ${TOPDIR}/downloads.
If it always downloads a particular component you must be either
changing the SRC_URI in the recipe
changing something else significant in the recipe
using something like HEAD in the SRC_URI which is changing between builds.
It might help if you posted the recipe.
See the documentation for DL_DIR here
Related
I'm playing with a Yocto project that has in its conf/bblayers.conf file the following line:
ADDONSLAYERS += "${#'${OEROOT}/layers/meta-qt5' if os.path.isfile('${OEROOT}/layers/meta-qt5/conf/layer.conf') else ''}"
I partially bitbaked the project but now I want to try to disable the whole meta-qt5 layer.
After commenting out the line above, how to remove the already built files from the output folder and go on with the others?
I tried with bitbake -c cleansstate meta-qt5 but it doesn't work. I guess it works with recipes only, and not with whole layers.
Easiest way to clean a build is to remove TMPDIR temporary folder (default is <build>/tmp).
That will remove previous compilation results, but those are also kept in SSTATE_DIR cache folder. Next build will not rebuild all, it will reuse cache results to speed it up.
Then, you can clean your cache folder for obsolete entries with sstate-cache-management.sh script:
# Example of usage (after sourcing oe-init-build-env)
sstate-cache-management.sh --cache-dir=../sstate-cache -d -y
i'm trying to apply a patch during the creation of my image with bitbake commande.
i have my file: u-boot-tftp.pacth under the directory: /file/u-boot-tftp.
here is my u-boot-tftp.bbappend :
DEPENDS += "dtc-native"
SRC_URI = "file://u-boot-tftp.patch"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
while building my image, im having this error :
Applying patch u-boot-tftp.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
No file to patch. Skipping patch.
2 out of 2 hunks ignored
Patch u-boot-tftp.patch does not apply (enforce with -f)
i tried to run the unpack commande : bitbake -c unpack -f u-boot-tftp but it din't work, i looked it up the internet and nothing seems to work.
Any help would be appreciated.
thanx
best regards.
You are overriding the SRC_URI variable in your bbappend. So the original U-Boot sources are not used and the U-Boot recipe has only your patch as the whole source.
Use SRC_URI += instead of SRC_URI = in you bbappend (like you did with DEPENDS).
can't find file to patch at input line 3
From the above error, it seems that yocto is unable to locate the patch. You can either update FILESEXTRAPATHS_prepend path or change the directory where the patch is located.
While executing do_patch(), it will search patch for multiple paths which can be seen in build/tmp/work//u-boot-tftp//temp/log.do_patch. Check whether it searches for the patch in "/file/u-boot-tftp" folder or not. and update the path accordingly.
Build is a module which has been developed in order to build the PDG.
I wrote a script which uses this module Build but when i try to launch this script with:
frama-c -load-script test.ml
I get the mistake: Unbound module Build.
Is there a way to get access to this module. I need it in my project.
Build is an example but there are another modules like Sets which provides functions to read a PDG. However, others modules like PdgTypes don't make mistakes. If anybody could help me...
In my file test.ml,
let compute = Build.compute_pdg
....
let () = Db.Main.extend main
You can't do that. -load-script can only work for script that do not have any dependency outside of Frama-C (or Frama-C's own dependencies such as OCamlgraph). As suggested by Anne, if your code is contained in more than one file, you should write it as a plugin.
For a simple plugin, you basically only have to write a short Makefile in addition to your OCaml code. This Makefile will mainly contain the list of source files of your plugin and a few additional information (such as the plugin's name), as explained in the developer's manual, which contain a small tutorial.
Alternatively, if you have only two files, it should be possible to assemble them manually into a single module that can then be loaded by Frama-C. Supposing you have build.ml and test.ml, you could do (with the Sodium
version)
ocamlopt -I $(frama-c-config -print-libpath) -c build.ml
ocamlopt -I $(frama-c-config -print-libpath) -c test.ml
ocamlopt -shared -o script.cmxs build.cmx test.cmx
frama-c -load-module script.cmxs [other options] [files]
The modules you refer to, Build and Sets, are not considered as being part of the public user interface of Frama-C. Instead, they are internal to the plugin PDG. The modules of PDG you can access from user scripts are those in the directory src/pdgTypes: PdgIndex, PdgMarks and PdgTypes. Then, a second part of the API is available inside Db.Pdg (Db is in src/kernel/db.ml). In particular, most of the functions of the module Sets are re-exported there.
For the functions available inside Build, they have been deemed too low-level to be exported. If you really need to access it, you will have to copy the directory src/pdg and transform it into a plugin (with a new name, to avoid clashes).
I added a simple JavaScript test to /src/chrome/test/data/webui/ and included the file in /src/chrome/chrome_tests.gypi.
I built it like this: ninja -C out/Debug browser_tests. That takes a while though. Is there a way to rebuild my test only, without also building all the other browser tests?
browser_tests is the only executable target to compile those tests so you need to use it in any case even if you perform a change in a single test. But you may want to try shared library compilation to improve the speed of your builds. For that just export GYP_DEFINES='component=shared_library' and then ./build/gyp_chromium before recompiling.
NOTE: This answer is not applicable to webui tests (they do not depend on test_data_dir_. Further, it is only relevant to Linux.
Some test files is not compiled into browser_tests. For these cases, just set the CR_SOURCE_ROOT environment variable to the Chromium source directory, e.g. (if your Chromium source files are located at ~/chromium/src)
CR_SOURCE_ROOT=~/chromium/src/ ./out/Debug/browser_tests
I discovered this when I tried to figure out why the extension tests did not run. I started with looking up the error message in the source code:
Extension error: Could not load extension from ''. Manifest file is missing or unreadable.
After some debugging with gdb, I found that the test extension that is supposed to be loaded by ExtensionBrowserTest::LoadExtensionWithFlags did not load because the path was invalid. path was somehow set to "extensions/api_test/webrequest", and because this is not an absolute path, it was cleared in UnpackedInstaller::GetAbsolutePath by extension_path_ = base::MakeAbsoluteFilePath(extension_path_);.
Consequently, Chromium tries to load an extension from location "" (empty string), which obviously fails.
Ultimately, I tracked down the cause to test_data_dir_, which is initialized at DIR_TEST_DATA, which in turn is derived from DIR_SOURCE_ROOT, which in turn is read from the CR_SOURCE_ROOT environment variable. With the following command, my tests ran again, and I was able to update the extension tests without recompiling.
CR_SOURCE_ROOT=~/chromium/src/ ./out/Debug/browser_tests
I'm modifying an automated build, and want to tell rpmbuild to use a specific build area when invoking it.
This is similar to an existing question, but more specific.
I don't want to run any of the build commands as the root user; the aim is only to have an RPM, not to install anything into the system.
I don't want to require the user to change their dotfiles (e.g. $HOME/.rpmrc); the build should be self-contained and not affect the user's existing settings.
I don't want to hard-code the location into the foo.spec file; that file should be useable as-is if the user wants to build in a different location.
The --buildroot option is not what I need; that sets a pseudo-root filesystem for the make part of the build process, but I need to specify the “build area” for the entire RPM build process.
What I'm looking for is a hypothetical --build-area FOODIR option that can be given to the rpmbuild command, or an equivalent environment variable. It should thus affect just that single invocation of the command and cause it to use a specified user-writable location for its build area.
I've seen references to a _topdir macro that seems to be what I'm talking about, but it doesn't appear to be configurable per invocation.
It would be ideal if rpmbuild could set up its own environment in that location when it needs it, but I don't mind setting up the directories for that per build, since that can be automated as part of the build. The goal is to have that user-writable location exist only for the duration of the build run, and then clean up by deleting that entire location once the RPM file is generated.
It's not documented, but the _topdir macro determines the build area.
So you can set this per-invocation with rpmbuild --define "_topdir ${PWD}/foobar" ... to set the directory to whatever you want.
--define is the key to setting values for any macro, not just _topdir.
The --buildroot option is not what you are looking for. The name is a bit misleading as it is not changing the buildroot but instead is setting the root for the install phase of the build. RPM is basically doing a "make install" as part of the build and is then packing the results of this. The buildroot option allows you to do this install into for example /tmp/myinstallroot.
I recently had to integrate rpm package building into an automated build and had the same problem. What i did was to generate a custom .rpmmacros file with %topdir set appropriately. I then just temporarily changes HOME to the location of that custom .rpmmacros file.
"HOME=mytopdir rpmbuild ...".