I face a problem that I tried to use the BitBake override style removal with variable expansion.
I have a foo.bb and set FOO_PACKAGES = "${PN}_dummy"
And I use a foo.bbappend to remove it by FOO_PACKAGES_remove = "${PN}_dummy"
This doesn't work.
However, FOO_PACKAGES_remove = "foo_dummy" works fine.
Furthermore I tried other variable names besides PN, e.g.
FOO_PACKAGES = "foo_dummy"
FOONAME = "foo"
FOO_PACKAGES_remove = "${FOONAME}_dummy"
This doesn't work either.
So maybe there is some issue with variable expansion in the override style removal?
I use BitBake 1.22 and am sorry I cannot test the master branch on my working environment.
BitBake Build Tool Core version 1.22.0, bitbake version 1.22.0
Does somebody have some idea about the behavior?
I suspect you need this patch:
http://git.openembedded.org/bitbake/commit/lib/bb/data_smart.py?h=1.24&id=72a1ca4a104ccab73d6abcbd44db9c2636a58572
which is in bitbake 1.24 and above.
Related
I'm having problem understanding how to correctly set the COMPILE_DEFINITIONS target properti in CMake.
my target is add_library(modelutilities STATIC ${modelutilities_SRCS})
I if use
set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} ${Qt5Widgets_COMPILE_DEFINITIONS})
set_target_properties(modelutilities PROPERTIES
VERSION "0.0.1"
SOVERSION 0
EXPORT_NAME "ModelUtilities"
ARCHIVE_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
LIBRARY_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/lib"
RUNTIME_OUTPUT_DIRECTORY "${modelutilities_PlatformDir}/bin"
COMPILE_DEFINITIONS ${modelutilities_COMPILE_DEFINE}
)
everything works fine, but if I add another line between them with set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} MODELUTILITIES_LIB) it stops working complaining that set_target_properties was called with the wrong number of arguments.
Anyone can spot what I'm doing wrong?
P.S.
I already tried using doublequotes: set(modelutilities_COMPILE_DEFINE ${modelutilities_COMPILE_DEFINE} "MODELUTILITIES_LIB"). It did not change anything
P.P.S.
If I message(STATUS ${modelutilities_COMPILE_DEFINE}) QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB in the first case and QT_WIDGETS_LIB;QT_GUI_LIB;QT_CORE_LIB;MODELUTILITIES_LIB in the second
With newer version of CMake, what is being preached is the idea of targets. So, for example, instead of include_directories() it's now preferred to use target_include_directories().
That being the case I think you'd be better served using the preferred target_compile_definitions() to set compile definitions for your utilities library.
One advantage you get is that your can scope your compile definitions using the PUBLIC or PRIVATE keywords.
I have two recipes that build an embedded linux image, call them A.bb and B.bb. I have a kernel patch that needs to be applied to one recipe but not the other. Following these docs I created my own layer and added a bbappend <your-layer>/recipes-kernel/linux/linux-yocto_3.4.bbappend and inside I put SRC_URI|+="kernel.patch". How can I do something like the following:
if (A):
SRC_URI+="kernel.patch"
else:
SRC_URI+=""
I tried the following:
Inside A.bb, I have export IMAGE_NAME="A"
Then inside linux_yocto_3.4.bbappend I have
SRC_URI_append = " ${#bb.utils.contains('IMAGE_NAME', 'A', 'file://kernel.patch', '', d)} "
But this doesn't work. Thank you for your help!
You can't.
A recipe can't influence how anything else is built; an image is just a recipe, thus is can't modify how the kernel is being built nor patched.
How can i override default make parameters , which is:
make -w
Each time i create a project , i had to modify project settings , adding -j4 to make parameters.
Can i set make -w -j4 by default ?
EDIT
The best way to do this is setting MAKEFLAGS environment variable , i'm picking the only answer as the best only to shut this thread down.
To set this for UNIX, modify the *.desktop file of Qt Creator , prefix the line entitled Exec= with env MAKEFLAGS=-j4 , but be aware that you won't be able to cease building in QtCreator immediately after setting to multithread.
To make it global and permanent go to
Tools > Options > Build & Run > Kits > (pick your toolchain)
and fill your predefined env settings: MAKEFLAGS=-j4
In the qtcreator go to the "Projects tab" and set "Make arguments" as you like:
If you want -jx parameter to be default each time you create a new or open some project, you must add enviroment variable MAKEFLAGS to your system with value -jx.
For example, at ubuntu for 8 - threding compilation this options can be realized by adding
MAKEFLAGS="-j8"
to /etc/enviroments
Result will be:
After attempting implement the fix described in the question I eventually found the following (clearly this in only a solution to linux's that use the freedesktop concept of .desktop files):
The line in "/usr/local/share/applications/Nokia-QtCreator.desktop" was:
Exec=/opt/qtcreator-2.5.2/bin/qtcreator.sh %F
I changed it to:
Exec=env MAKEFLAGS=-j16 /opt/qtcreator-2.5.2/bin/qtcreator.sh %F
And got the functionality requested in the question.
Ok, I have no idea why following the instructions in the question I didn't get there but I didn't. I hope this explanation will help someone.
If I provide a variable with an embedded space in the environment as follows:
environment =
CPPFLAGS="-D_GNU_SOURCE -I${openssl:location}/include"
I get this error:
ValueError: dictionary update sequence element #1 has length 1; 2 is required
Is this a bug? Is there a workaround?
It's a shortcoming in zc.recipe.cmmi; it cannot handle environment variables without spaces. There is a patch available in the bugtracker for the recipe.
I am not currently aware of a workaround for this other than applying the patch. You can apply the patch on existing eggs using the collective.recipe.patch recipe, which should work in this case too (untried):
[buildout]
parts =
patch-z.r.cmmi
yourcmmipart
[patch-z.r.cmmi]
recipe = collective.recipe.patch
egg = zc.recipe.cmmi <= 1.3.4
patch = patches/environ_section_trunk_r101308.patch
This assumes you have a patches suddirectory with the patch from the bug downloaded. The part needs to be listed before your cmmi part to be executed before that part (or you can fabricate a dependency).
An alternative solution is to just abuse the recipe's 'configure-command' like so:
[buildthis]
recipe = zc.recipe.cmmi
...
configure-command =
export CPPFLAGS="-D_GNU_SOURCE -I${openssl:location}/include";
./configure
In a larger project, I have set up ./tests/Makefile.am to run a number of tests when I call make check. The file global_wrapper.c contains the setup / breakdown code, and it calls test functions implemented in several subdirectories.
TESTS = global_test
check_PROGRAMS = global_test
global_test_SOURCES = global_wrapper.c foo/foo_test.c bar/bar_test.c
Works great. But the tests take a long time, so I would like to be able to optionally execute only tests from a single subdir. This is how I did it at first.
I added the subdirectories:
SUBDIRS = foo bar
In the subdirectories, I added local wrappers and Makefile.am's:
TESTS = foo_test
check_PROGRAMS = foo_test
# the foo_test.c here is of course the same as in the global Makefile.am
foo_test_SOURCES = foo_wrapper.c foo_test.c
This, too, works great - when I call make check in the subdirectory foo, only the foo tests are executed.
However, when I now call make check in ./tests, all tests are executed twice. Once through global_test, and once through the local test programs.
If I omit the SUBDIRS statement in the global Makefile.am, the subdirectory makefiles don't get build. If I omit TESTS from the local Makefile.am's, make check doesn't do anything for the local directories.
I'm not that familiar with automake, but I am pretty sure there is some way to solve this dilemma. Can anybody here give me a hint?
Break your tests up. In your tests/Makefile.am do:
TESTS = foo_test bar_test
and build foo_test bar_test appropriately with something like
foo_test_SOURCES = foo/foo_wrapper.c foo/foo_test.c
bar_test_SOURCES = bar/bar_wrapper.c bar/bar_test.c
Now, if you do a raw 'make check', both tests will be run. If you only want to run one test, you can do that with 'make check TESTS=foo_test' or 'make check TESTS=bar_test' and only the appropriate test will run. Typically, the Makefile.am lists all the tests that will be run by default in TESTS and the user selects alternate tests at make-time. Naturally, if you are running the tests a lot, you can 'export TESTS=foo_test' in your shell session and then only type 'make check'.
Can't you remove from "global_test" any test that is already executed in a subdirectory? (Just so they simply don't get executed twice.)
I think you could maybe overwrite the check rule at the top-level to define an environment variable:
check:
DISABLE_SUBTESTS=1 make check-recursive
and then test DISABLE_SUBTESTS in your sub-directories to decide whether to actually run the tests or not.
(Personally, I'd rather arrange to work in the existing make check framework by concealing the output of my tests, rather than overwriting the produced rules like this.)