After the following lines:
export CROSS_COMPILE=/home/yourusername/NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-
make clean && make mrproper
make maker.defconfig gives me this error:
Can't find default configuration "arch/x86/configs/filename_defconfig".
It is searching in x86/configs/filename_defconfig instead of arm/configs/filename_defconfig. How do I change the path?
You are just missing an export:
export ARCH=arm //Or whatever architecture you're compiling for
export CROSS_COMPILE=/home/yourusername/NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-
make clean && make mrproper
Please be advised you're only cleaning the kernel build this way, to actually compile it replace the make command with these ones (you still need the exports):
make <target config file>
make -j<number of cores you wish to use for compilation>
You can also add the export lines directly to the make command like so:
make ARCH=arm CROSS_COMPILE=/home/yourusername/NDK/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- <make target>
Related
I have a Nightwatch + BrowserStack configuration on my project and I'm trying to add custom commands to my project to compare 2 screenshots using resemble.js .
I configure my nightwatch.json file with this :
"custom_commands_path": "./node_modules/nightwatch/commands",
"custom_assertions_path": "./node_modules/nightwatch/assertions"
I put the commands file in the folder and I tried to run my test in every directory possible to see if it was a path problem. I've also tried with different commands, some of them I get online and even the default example one. Whatever I run it returns nameOfTheCommand is not a function. So I guess it does not even find the path to the customs commands in the nightwatch.json file.
Is there anything I'm missing here? I'm quite new so the answer could be very simple but I tried every .json file of my project in case there was a special configuration linked to BrowserStack.
Path to the custom commands should be analogous to the path to custom commands. You should point a folder where you added them.
I've found that if I put them in the suite configuration file, it picks them up:
nightwatch_config = {
src_folders: ["tests/suite/product/"],
page_objects_path: "pages/product",
custom_commands_path: "./custom_commands"
}
I need to test in the browser because I am using WebAudio. Okay, so since I'm using tape, I run
browserify -t babelify index.js | browser-run -p 3000
The problem is that I'm using Nitrous.io, so the test complains:
Error: Cannot find module '__mySource/models/audio' from '/home/nitrous/code/mrr/source/__mySource/test/audio/model/metronome'
So now I need I need to go into my code and customize all imports for the sake of Nitrous. So instead of
import {initialize} from '__mySource/models/audio';
I now need to hack all imports
import {initialize} from '/home/nitrous/code/mrr/source/__mySource/models/audio';
which is clearly unacceptable. Hopefully there is a simple fix for this problem.
Typically I recommend that developers should use relative paths (starting with a './' or '../') when importing or requiring files. Absolute paths can vary from machine to machine so those are also problematic.
It is possible to define aliases that act like pseudo-packages but those can be tricky to configure and are often more confusing to developers than just using the standard commonjs naming.
So try using relative paths for your imports (or requires) that don't refer to files inside another actual package.
I'm trying to reconfigure some .config variables to generate a modified kernel with wifi support enabled. The native layer/recipe for the kernel is located in this directory:
meta-layer/recipes-kernel/linux/linux-yocto_3.19.bb
First I reconfigure the native kernel to add wifi support (for example, adding CONFIG_WLAN=y):
$ bitbake linux-yocto -c menuconfig
After that, I generate a "fragment.cfg" file:
$ bitbake linux-yocto -c diffconfig
I have created this directory into my custom-layer:
custom-layer/recipes-kernel/linux/linux-yocto/
I have copied the "fragment.cfg file into this directory:
$ cp fragment.cfg custom-layer/recipes-kernel/linux/linux-yocto/
I have created an append file to customize the native kernel recipe:
custom-layer/recipes-kernel/linux/linux-yocto_3.19.bbappend
This is the content of this append file:
FILESEXTRAPATHS_prepend:="${THISDIR}/${PN}:"
SRC_URI += "file://fragment.cfg"
After that I execute the kernel compilation:
$ bitbake linux-yocto -c compile -f
After this command, "fragment.cfg" file can be found into this working directory:
tmp/work/platform/linux-yocto/3.19-r0
However none of the expected variables is active on the .config file (for example, CONFIG_WLAN is not set).
How can I debug this issue? What is supposed I'm doing wrong?
When adding this configuration you want to use append in your statement such as:
SRC_URI_append = "file://fragment.cfg"
After analyzing different links and solutions proposed on different resources, I finally found the link https://community.freescale.com/thread/376369 pointing to a nasty but working patch, consisting in adding this function at the end of append file:
do_configure_append() {
cat ${WORKDIR}/*.cfg >> ${B}/.config
}
It works, but I expected Yocto managing all this stuff. It would be nice to know what is wrong with the proposed solution. Thank you in advance!
If your recipe is based on kernel.bbclass then fragments will not work. You need to inherit kernel-yocto.bbclass
You can also use merge_config.sh scripts which is present in kernel sources. I did something like this:
do_configure_append () {
${S}/scripts/kconfig/merge_config.sh -m -O ${WORKDIR}/build ${WORKDIR}/build/.config ${WORKDIR}/*.cfg
}
Well, unfortunately, not a real answer... As I haven't been digging deep enough.
This was working alright for me on a Daisy-based build, however, when updating the build system to Jethro or Krogoth, I get the same issue as you.
Issue:
When adding a fragment like
custom-layer/recipes-kernel/linux/linux-yocto/cdc-ether.cfg
The configure step of the linux-yocto build won't find it. However, if you move it to:
custom-layer/recipes-kernel/linux/linux-yocto/${MACHINE}/cdc-ether.cfg
it'll work as expected. And it's a sligthly less hackish way of getting it to work.
If anyone comes by, this is working on jethro and sumo:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " \
file://fragment.cfg \
"
FILESEXTRAPATHS documentation says:
Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append files. The directories BitBake uses when it processes recipes are defined by the FILESPATH variable, and can be extended using FILESEXTRAPATHS.
I would like to start a container with the basic ubuntu template - but I'd like it to automatically install a couple of extra packages - or ideally run a bash script.
It seems like I should be using hooks, and when I create a container pass in a configuration file which sets a particular hook as my bash script. But I can't help but think there must be an easier way?
Recent versions of the lxc-ubuntu template supports a --packages option which lets you get extra packages in there.
Otherwise, you can indeed use a start hook to run stuff inside the container.
If using the ubuntu-cloud template, you could also pass it a cloud-init config file which can do that kind of stuff for you.
Or if you just want to always do the same kind of configuration, simply create an ubuntu container, start it, customize it to your liking and from that point on, just use lxc-clone instead of lxc-create to create new containYou can indeeders based on the one you customized.
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.