From: Tobias Henkel
The icecc class often calls 'which' for determining paths. This leads
to many messages on stderr in case 'which' doesn't find the
executable. Using bb.utils.which is more appropriate here and doesn't
pollute stderr.
Signed-off-by: To
On 11/12/2013 12:04 PM, Enrico Scholz wrote:
-return d.getVar('ICECC_PATH') or os.popen("which icecc").read()[:-1]
+return d.getVar('ICECC_PATH') or os.popen("which icecc 2>
/dev/null").read()[:-1]
~~
I think, this can/should
From: Tobias Henkel
In the current implementation there can be a race condition while
creating the toolchain archive causing the build to break.
This is fixed by locking the toolchain archiving step using flock.
Signed-off-by: Tobias Henkel
---
meta/classes/icecc.bbclass | 31
From: Tobias Henkel
In the current implementation a KERNEL_CC variable containing shell
evaluation breaks the build process. Shell expansion is not happening
before general expansion in get_cross_kernel_cc which results in a
syntax error and an aborted parse process.
Before expanding the
From: Tobias Henkel
Some packages are calling the compiler in the install step. In this
case either the build breaks or icecc is not used for building. The
proper environment has to be set to enable icecc based building.
Signed-off-by: Tobias Henkel
---
meta/classes/icecc.bbclass | 6
From: Tobias Henkel
The icecc class often uses 'which' for determining paths. This leads
to many messages on stderr in case 'which' doesn't find the
executable. Redirecting stderr to /dev/null inhibits these messages as
the result is handled correctly anyway.
Sig
From: Tobias Henkel
There are some recipes which parse the PARALLEL_MAKE variable by their
own and set them to an empty string afterwards. This disables icecc
for this recipe.
Adding a whitelist for forcing icecc makes it possible to use icecc
also with these recipes.
Signed-off-by: Tobias
From: Tobias Henkel
The current implementation doesn't give a hint about the cause in case
something went wrong in set_icecc_env. This makes it harder to find
out why a package is not being built using icecc. Therefore warnings
are inserted in the various error cases.
Signed-off-by: T
From: Tobias Henkel
Hello,
while trying to get icecc work I faced some issues which are addressed
in this patch series.
First it was difficult to find out the reason why some packages don't
use icecc because the relevant information was missing in the
logs. There were also some messages
From: Tobias Henkel
Changing any of the ICECC blacklist variables should not change the
sstate checksum as this doesn't influence the build result.
Signed-off-by: Tobias Henkel
---
meta/classes/icecc.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/cl
From: Tobias Henkel
Currently the icecc class prints a note for every package which
disables parallel make at parse time. This is unneccessary as many
packages don't support parallel building. Changing the log level from
info to debug hides these messages in normal builds without removin
From: Tobias Henkel
Bitbakes prepend mechanism for the tasks disregards the type of the
function. Thus bitbaking recipes using python functions for configure,
compile or install steps fail due to the missing python version of
set_icecc_env.
Assuming that icecc doesn't need to be used in
12 matches
Mail list logo
