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 <mke...@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@columbia:~$ ls /opt/xos/nanopi-neo-plus2/*environment*
/opt/xos/nanopi-neo-plus2/environment-setup-aarch64-poky-
linux
martin@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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
