Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Laurentiu Palcu <laurentiu.palcu@intel.com>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 03/12] populate_sdk_base: Update extraction script for multilibs
Date: Mon, 01 Oct 2012 18:47:16 +0300	[thread overview]
Message-ID: <5069BB04.8050905@intel.com> (raw)
In-Reply-To: <5069B5E7.6010900@windriver.com>



On 10/01/2012 06:25 PM, Mark Hatle wrote:
> On 10/1/12 10:17 AM, Laurentiu Palcu wrote:
>>
>>
>> On 10/01/2012 05:55 PM, Mark Hatle wrote:
>>> On 10/1/12 8:17 AM, Richard Purdie wrote:
>>>> On Sat, 2012-09-29 at 19:19 -0500, Mark Hatle wrote:
>>>>> When multilibs are enabled, there will be more then one environment
>>>>> file created.  We need to be sure to process each environment file.
>>>>> The next function can simply use the last environment file processed
>>>>> to get the magic value(s) that it requires.
>>>>>
>>>>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>>>>> ---
>>>>>    meta/classes/populate_sdk_base.bbclass |    5 +++--
>>>>>    1 files changed, 3 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass
>>>>> index 6eb6726..1bc1438 100644
>>>>> --- a/meta/classes/populate_sdk_base.bbclass
>>>>> +++ b/meta/classes/populate_sdk_base.bbclass
>>>>> @@ -158,8 +158,9 @@ echo "done"
>>>>>
>>>>>    printf "Setting it up..."
>>>>>    # fix environment paths
>>>>> -env_setup_script=$(find $target_sdk_dir/ -name "environment-setup-${REAL_MULTIMACH_TARGET_SYS}")
>> The reason to replace globbing with ${REAL_MULTIMACH_TARGET_SYS} was to
>> match only the file we're interested in and avoid matching other files
>> whose names start with environment-setup. However, since all the
>> environment-setup directories reside in $target_sdk_dir/ we would
>> probably be safer, and faster, by doing a simple ls and avoid searching
>> all the tree.
>>
>> env_setup_script=$(ls $target_sdk_dir/environment-setup-*)
> 
> That seems reasonable to me, and a lot faster then the find.
Also, we should replace 'find' with 'ls' in adt_installer_internal
script (line 212) too. So that both the toolchain tarball installer and
adt-installer scripts are in sync.

> 
>>>>> -sed -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:g" -i $env_setup_script
>>>>> +for env_setup_script in `find $target_sdk_dir/ -name "environment-setup-*"` ; do
>>>>> +  sed -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:g" -i $env_setup_script
>>>>> +done
>> We could probably do this without the for loop since sed accepts
>> multiple input files.
> 
> The end result of the env_setups_script though, needs to only contain -one- 
> environment script (doesn't matter which one).  That's why I used the loop.
> 
>>>>>
>>>>>    # fix dynamic loader paths in all ELF SDK binaries
>>>>>    native_sysroot=$(cat $env_setup_script |grep OECORE_NATIVE_SYSROOT|cut -d'=' -f2|tr -d '"')
> 
> The code snippet above is the reason why it can only contain the one item.. but 
> it happens that OECORE_NATIVE_SYSROOT is the same in all environment files (and 
> has to be...)  So it's safe to just use the last processed item.
> 
> A for loop shouldn't be any slower then calling the set w/ multilib inputs and 
> then later adjusting the variable to only be one item.  (We're talking at a 
> maximum 3 environment scripts.. thus why it shouldn't be an issue.)

Agreed! I'm OK with the solution.

Thanks,
Laurentiu
> 
>>>>
>>>> This is on course to conflict with
>>>>
>>>> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1b6019086c4242c550b4e0551c7b5d206a0d52e1
>>>>
>>>> Can you please talk with Laurentiu and come up with a solution that
>>>> works for everyone.
>>>
>>> I think this is a better fix for the problem.  The other change limits the
>>> environment file to a single file.  However, there is nothing in the function --
>>> other then the use of 'env_setuo_script' -- that wants or needs a single file
>>> loaded.
>>>
>>> So it's better to find htem all and just iterate over them all.  Also the order
>>> of processing, and the last item processed does not matter.  The later chunks of
>>> functionality just look for a static value that is supposed to be the same in
>>> all of the environment files.
>>>
>>> --Mark
>>>
>>>> Cheers,
>>>>
>>>> Richard
>>>>
>>>
> 



  reply	other threads:[~2012-10-01 16:00 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-30  0:19 [PATCH 00/12] Multilib, duplicate deps, and misc cleanup Mark Hatle
2012-09-30  0:19 ` [PATCH 01/12] multilib: Add support for cross-canadian multilib packages Mark Hatle
2012-09-30  0:19 ` [PATCH 02/12] multilib - crosssdk: Stop building multilib for crosssdk packages Mark Hatle
2012-09-30  0:19 ` [PATCH 03/12] populate_sdk_base: Update extraction script for multilibs Mark Hatle
2012-10-01 13:17   ` Richard Purdie
2012-10-01 14:55     ` Mark Hatle
2012-10-01 15:17       ` Laurentiu Palcu
2012-10-01 15:25         ` Mark Hatle
2012-10-01 15:47           ` Laurentiu Palcu [this message]
2012-09-30  0:19 ` [PATCH 04/12] bb.utils.explode_dep_versions: Update to ensure we avoid duplicate deps Mark Hatle
2012-10-01 13:09   ` Richard Purdie
2012-10-01 14:53     ` Mark Hatle
2012-10-01 15:04       ` Richard Purdie
2012-09-30  0:19 ` [PATCH 05/12] package_deb/ipk: Remap < and > to << and >> Mark Hatle
2012-09-30  0:19 ` [PATCH 06/12] libxcb: Update DEPENDS to avoid duplicate entries Mark Hatle
2012-09-30  0:19 ` [PATCH 07/12] Cleanup: fix PN == BPN cases Mark Hatle
2012-09-30  0:19 ` [PATCH 08/12] multilib: Move redefinition of STAGING_DIR_KERNEL Mark Hatle
2012-09-30  0:19 ` [PATCH 09/12] rpm-native: Fix 'uuid_rc_t' undeclared error when compiling Mark Hatle
2012-09-30  0:19 ` [PATCH 10/12] rpm: Fix file contention issue Mark Hatle
2012-09-30  0:19 ` [PATCH 11/12] rpm: Add rpm patch to fix git_strerror issues Mark Hatle
2012-09-30  0:19 ` [PATCH 12/12] rpm: Implement workaround for DB_BUFFER_SMALL error Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5069BB04.8050905@intel.com \
    --to=laurentiu.palcu@intel.com \
    --cc=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox