[meta-freescale] [fsl-community-bsp-platform][PATCH] setup-environment: add options for the script

[Otavio Salvador]

On Sat, May 18, 2013 at 11:04 PM, Mahadevan Mahesh-R9AADQ
<r9aadq at freescale.com> wrote:
> On Fri, May 17, 2013 at 10:02 PM, Mahesh Mahadevan
> <Mahesh.Mahadevan at freescale.com> wrote:
>> From: Mahesh Mahadevan <mahesh.mahadevan at freescale.com>
>>
>> Add options to help specify the machine, below are the options added:
>> Usage: source ./setup-environment <-m machine>
>>     Optional parameters: [-j jobs] [-t tasks] [-h]
>>
>>  Supported machines: imx23evk imx28evk imx31pdk imx35pdk imx51evk imx53ard imx53qsb imx6dlsabresd imx6qsabreauto imx6qsabresd imx6slevk
>
> The meta-fsl-arm-extra machines are missing.
>
> [Mahadevan Mahesh-R9AADQ] Sure, will look into adding.

Good.

>>     * [-j jobs]: number of jobs for make to spawn during compile; default=4
>>     * [-t tasks]: number of bitbake tasks that can be issued in parallel; default=4
>
> I understand the need for it but I am a little concerned about using
> command line options. bitbake use environment to override things, so
> you can:
>
> MACHINE=wandboard-dual bitbake core-image-base
>
> and with the default local.conf, it will respect the environment
> variable. So we could support same thing, as:
>
> BB_NUMBER_THREADS=8 PARALLEL_MAKE='-j 12' source ./setup-environment <builddir>
>
> [Mahadevan Mahesh-R9AADQ] That's correct, but the idea behind doing this is to make it simpler for the user with some check for valid machine type.

The problem I see is not the machine validation (which can be done)
but the different way of work. If people use:

MACHINE=<machine> source ./setup-environment build

It will be natural for them to use:

MACHINE=<another machine> bitbake ...

So we're consistent on how to use things. You can validate the used
machine for setup-environment but using two ways for same thing is
confusing.

>>     * [-b path]: non-default build dir location; default location is /home/r9aadq/yocto/build
>
> This one I disagree; I think we always should pass build dir so user
> know where he is going.
>
> [Mahadevan Mahesh-R9AADQ] I can make the -b option mandatory
>
>>     * [-h]: help
>
> ok; please support --help here as well.
>
> [Mahadevan Mahesh-R9AADQ] Sure will do.

Ok

>> Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan at freescale.com>
>> ---
>>  setup-environment |   91 +++++++++++++++++++++++++++++++++++++++++++++++------
>>  1 file changed, 81 insertions(+), 10 deletions(-)
>>
>> diff --git a/setup-environment b/setup-environment
>> index 6aadbb4..96b1e26 100644
>> --- a/setup-environment
>> +++ b/setup-environment
>> @@ -17,13 +17,88 @@
>>  # with this program; if not, write to the Free Software Foundation, Inc.,
>>  # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>>  #
>> +# Add options for the script
>> +# Copyright (C) 2013 Freescale Semiconductor, Inc.
>> +
>> +NCPU=`grep -c processor /proc/cpuinfo`
>> +CWD=`pwd`
>> +
>> +usage()
>> +{
>> +    echo -e "\nUsage: source ${BASH_SOURCE[0]} <-m machine>
>> +    Optional parameters: [-j jobs] [-t tasks] [-h]"
>> +    echo -e -n "\n Supported machines: `ls $CWD/sources/meta-fsl-arm/conf/machine \
>> +    | grep -v "^include" | sed s/\.conf//g | xargs echo`"
>> +echo "
>
> Check other layers; you could:
>
> ls $CWD/sources/*/conf/machine/*.conf
>
> [Mahadevan Mahesh-R9AADQ] Thanks, will look into using this

Ok

>> +    * [-j jobs]: number of jobs for make to spawn during compile; default=$NCPU
>> +    * [-t tasks]: number of bitbake tasks that can be issued in parallel; default=$NCPU
>> +    * [-b path]: non-default build dir location; default location is $CWD/build
>> +    * [-h]: help
>
> Was commented above.
>
>> +}
>> +
>> +clean_up()
>> +{
>> +   unset EULA MACHINE JOBS THREADS LIST_MACHINES VALID_MACHINE BUILD_DIR
>> +   unset NCPU CWD TEMPLATES
>> +   unset imx_poky_setup_j imx_poky_setup_t imx_poky_setup_help imx_poky_setup_error
>
> Please drop imx prefix here; use fslc so it does not restrict to imx.
>
> [Mahadevan Mahesh-R9AADQ] Isn't this script intended for imx targets, or would you prefer I use fsl instead?

No; it is intended for use with fsl-community-bsp and we can have more
than i.MX here. Better to avoid 'imx' when something is not really
specific and this script has nothing specific.

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750