Re: Could we build tar-replacement firstly and not parallel if tar-replacement is needed to build

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2012-08-07 at 13:59 +0800, Rongqing Li wrote:
> Paste a RFC PATCH
> 
> [RFC PATCH 1/1] bitbake: compile tar-replacement firstly, and not parallel
> 
> Compiling tar-replacement or not is decided by version of host tar,
> if the host tar version is lower than 1.23, Compiling tar-replacement
> is needed.
> 
> When doing popoluate tar-replacement sysroot to write the tar to
> sysroot, but writing is not finished. other packages probably
> use the being written tar to unzip file, which will lead to failure
> and report the below error:
> "bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/tar: Text file busy "
> 
> Now we compile tar-replacement firstly and not parallel to ensure
> that a being written tar command will not be used.
> 
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
>   scripts/bitbake |   14 +++++++++++++-
>   1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/scripts/bitbake b/scripts/bitbake
> index 3772d82..eb6b144 100755
> --- a/scripts/bitbake
> +++ b/scripts/bitbake
> @@ -134,7 +134,19 @@ if [ $buildpseudo -gt 0 ]; then
>               fi
>           done
>       done
> -    bitbake pseudo-native $TARTARGET $additionalopts -c populate_sysroot
> +
> +    if [ $needtar = "1" ]; then
> +       NUM_THREAD_LINE=`grep -n "^\s*BB_NUMBER_THREADS" conf/local.conf 
> |awk -F':' '{print $1}'`
> +	test -n "$NUM_THREAD_LINE" &&
> +	sed -i ''"$NUM_THREAD_LINE"'s/^\s*BB_NUMBER_THREADS/#\0/g' conf/local.conf
> +
> +	bitbake $TARTARGET -c populate_sysroot
> +
> +	test -n "$NUM_THREAD_LINE" &&
> +	sed -i 
> ''"$NUM_THREAD_LINE"'s/^#\s*BB_NUMBER_THREADS/BB_NUMBER_THREADS/g' 
> conf/local.conf
> +    fi

We are *NOT* running sed over local.conf. What is the user used a
different configuration file for example?

If you're just building tar-native, is there a parallel race possible?
I'm not sure that there is?

For the record I hate this script and what it has become, its horrible.
It started as a workaround for pseudo-native, its becoming a dumping
ground for a whole set of nasty workarounds :(.

Cheers,

Richard