[OE-core] [PATCH v2 5/7] toolchain-shar-extract: pass env to post-relocate

[Martin Kelly]

On 06/04/2018 11:42 AM, Joshua Watt wrote:
> On Mon, 2018-06-04 at 11:24 -0700, Martin Kelly wrote:
>> On 06/04/2018 11:20 AM, Joshua Watt wrote:
>>> On Mon, 2018-06-04 at 11:10 -0700, Martin Kelly wrote:
>>>> On 06/04/2018 10:20 AM, Joshua Watt wrote:
>>>>> On Fri, 2018-06-01 at 15:24 -0700, Martin Kelly wrote:
>>>>>> On 06/01/2018 03:08 PM, Joshua Watt wrote:
>>>>>>> On Fri, 2018-06-01 at 14:02 -0700, Martin Kelly wrote:
>>>>>>>> It's useful for the post-relocate scripts to be able to
>>>>>>>> see
>>>>>>>> the
>>>>>>>> SDK
>>>>>>>> environment, for example to see the values of CC, CXX
>>>>>>>> etc. in
>>>>>>>> order
>>>>>>>> to
>>>>>>>> dynamically generate toolchain files.
>>>>>>>>
>>>>>>>> To enable this, source the SDK environment script prior
>>>>>>>> to
>>>>>>>> calling
>>>>>>>> the
>>>>>>>> relocate scripts.
>>>>>>>>
>>>>>>>> Signed-off-by: Martin Kelly <mkelly at xevo.com>
>>>>>>>> ---
>>>>>>>>      meta/classes/toolchain-scripts.bbclass     | 17
>>>>>>>> +++++++++++++
>>>>>>>> ----
>>>>>>>>      meta/recipes-core/meta/meta-environment.bb |  5 +++--
>>>>>>>>      2 files changed, 16 insertions(+), 6 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/meta/classes/toolchain-scripts.bbclass
>>>>>>>> b/meta/classes/toolchain-scripts.bbclass
>>>>>>>> index ae7bbef034..5f99fd8c03 100644
>>>>>>>> --- a/meta/classes/toolchain-scripts.bbclass
>>>>>>>> +++ b/meta/classes/toolchain-scripts.bbclass
>>>>>>>> @@ -118,11 +118,20 @@ EOF
>>>>>>>>      }
>>>>>>>>      
>>>>>>>>      toolchain_create_post_relocate_script() {
>>>>>>>> -	script=$1
>>>>>>>> -	rm -f $script
>>>>>>>> -	touch $script
>>>>>>>> +	relocate_script=$1
>>>>>>>> +	sdk_script=$2
>>>>>>>> +	rm -f $relocate_script
>>>>>>>> +	touch $relocate_script
>>>>>>>> +
>>>>>>>> +    cat >> $relocate_script <<EOF
>>>>>>>> +# Source the SDK env script in case it is needed for the
>>>>>>>> relocate
>>>>>>>> scripts.
>>>>>>>> +. $sdk_script
>>>>>>>
>>>>>>> I had originally done something similar to this when I
>>>>>>> added
>>>>>>> support
>>>>>>> for the post-relocate scripts with icecream. However, it is
>>>>>>> insufficent
>>>>>>> because there can be multiple SDK environment scripts that
>>>>>>> need
>>>>>>> to
>>>>>>> be
>>>>>>> sourced. In order to get a fully correct environment, I had
>>>>>>> to
>>>>>>> do:
>>>>>>>
>>>>>>>      # Setup environment
>>>>>>>      for env_setup_script in `ls $1/environment-setup-*`; do
>>>>>>>      	. $env_setup_script
>>>>>>>      done
>>>>>>>
>>>>>>> see meta/recipes-devtools/icecc-toolchain/icecc-
>>>>>>> toolchain/icecc-
>>>>>>> setup.sh
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> There's one overall "SDK environment" script (the one you
>>>>>> source
>>>>>> as
>>>>>> a
>>>>>> user to enter the SDK environment), and also customizable
>>>>>> ones
>>>>>> installed
>>>>>> by nativesdk-* packages (e.g. one that cmake uses). In this
>>>>>> patch, I
>>>>>> had
>>>>>> not intended that post-relocate scripts should be able to see
>>>>>> the
>>>>>> environment scripts for every project but instead just for
>>>>>> the
>>>>>> global
>>>>>> SDK enivorment (to get at variables like
>>>>>> OECORE_NATIVE_SYSROOT).
>>>>>
>>>>> (Almost) All of the code I can find that deals with the SDK
>>>>> environment
>>>>> supports multiple top level environment-setup-* files. If you
>>>>> happen to
>>>>> have more than one, the relocation script will relocate all of
>>>>> them
>>>>> (meta/files/toolchain-shar-relocate.sh), and the extraction
>>>>> script
>>>>> will
>>>>> give you instructions to source them all (meta/files/toolchain-
>>>>> shar-
>>>>> extract.sh).
>>>>>
>>>>> It's possible this is some left over anachronism and it has no
>>>>> actual
>>>>> use, but we should either fix it everywhere else or be
>>>>> consistent
>>>>> here.
>>>>>
>>>>
>>>> OK, that's good to know.
>>>>
>>>>>>
>>>>>> Let me know if I have missed something and not including the
>>>>>> other
>>>>>> environments could cause breakage.
>>>>>>
>>>>>> Here's what I mean from an example extracted SDK:
>>>>>>
>>>>>> martin at columbia:~$ ls /opt/xos/nanopi-neo-plus2/*environment*
>>>>>> /opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-
>>>>>> linux
>>>>>>
>>>>>> martin at columbia:~$ ls
>>>>>> /opt/xos/nanopi-neo-plus2/sysroots/x86_64-xevo-
>>>>>> linux/environment-
>>>>>> setup.d/
>>>>>> cmake.sh
>>>>>>
>>>>>> In the above example, we are currently sourcing only
>>>>>> /opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-
>>>>>> linux
>>>>>> and
>>>>>> not
>>>>>> cmake.sh.
>>>>>
>>>>> Sort of.... environment-setup-aarch64-poky-linux is going to
>>>>> implicitly
>>>>> source the cmake.sh script (see the for loop at the end of the
>>>>> script)
>>>>>
>>>>
>>>> Yes, I see that now. Given that the top-level environment-setup
>>>> script
>>>> implicitly sources the individual project sh scripts, isn't it
>>>> correct
>>>> to source only the top-level one? In that way, if the path to the
>>>> individual sh scripts changes, this code won't break, and it
>>>> leaves
>>>> the
>>>> top-level script to the single source of truth with regard to
>>>> environment setup scripts.
>>>
>>> Yes I agree. I think there was some miscommunication, I wasn't
>>> suggesting that we should be sourcing those manually. I just wanted
>>> to
>>> handle the top level environment-setup-* scripts in a consistent
>>> manner
>>> to the rest of the code (i.e. make sure we source all of them).
>>>
>>
>> OK, before I move to the next revision, let me make sure I
>> understand
>> you correctly:
>>
>> - There may be multiple top-level environment setup scripts.
>>
>> - The environment setup script that is always created
>> (environment-setup-aarch64-poky-linux in our example) sources all
>> the
>> project-specific files.
>>
>> - Thus, we should source all top-level environment scripts, but not
>> any
>> project-specific ones, as they will be pulled in implicitly.
>>
>> Is that correct?
> 
> That sounds correct
> 

OK, I'll send a v3 soon.