esdk without using Poky?

esdk without using Poky?

[Gary Thomas]

I'm trying to build an extensible SDK (eSDK) for my target and running into
a few problems.

   gthomas@zeus:~$ /work/tmp/mlb-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh
   MLB @SDK_TITLE@ Associates Embedded (Poky/Yocto Powered) Extensible SDK installer version 2.2+snapshot
   ======================================================================================================
   Enter target directory for SDK (default: ~/mlb_sdk):
   You are about to install the SDK to "/home/gthomas/mlb_sdk". Proceed[Y/n]? y
   Extracting SDK.........................................done
   Setting it up...
   Extracting buildtools...
   Preparing build system...
   Error: 'meta-poky/conf' must be a directory containing local.conf & bblayers.conf

The first thing I notice is the banner which should read:
   MLB & Associates Embedded (Poky/Yocto Powered) Extensible SDK installer version 2.2+snapshot
   ============================================================================================

The second is that I use my own distribution (not poky).  How can I
build an eSDK using my distribution?

Once I ran into this error, I tried rebuilding using the [old] SDK.
I noticed that it seemed to rebuild [most] everything all over again.
Is there no shared state / reusable components between the eSDK and SDK?

Finally, since I had to install SDK and not eSDK, I'm missing some tools
I was hoping to have.  I want to build PRU programs for the BeagleBoneBlack
and I'm using meta-ti to import those tools and programs.  I was expecting
the PRU tools which come from ti-cgt-pru-native to be included with my
eSDK/SDK, but they don't seem to be, at least not in the SDK.  How can I
get these tools available so I can use the SDK to develop PRU code for the BBB?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Paul Eggleton]

Hi Gary,

On Mon, 31 Oct 2016 13:19:18 Gary Thomas wrote:
> I'm trying to build an extensible SDK (eSDK) for my target and running into
> a few problems.
> 
>    gthomas@zeus:~$
> /work/tmp/mlb-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh MLB
> @SDK_TITLE@ Associates Embedded (Poky/Yocto Powered) Extensible SDK
> installer version 2.2+snapshot
> ===========================================================================
> Enter target directory for SDK (default:
> ~/mlb_sdk):
>    You are about to install the SDK to "/home/gthomas/mlb_sdk".
> Proceed[Y/n]? y Extracting SDK.........................................done
>    Setting it up...
>    Extracting buildtools...
>    Preparing build system...
>    Error: 'meta-poky/conf' must be a directory containing local.conf &
> bblayers.conf
> 
> The first thing I notice is the banner which should read:
>    MLB & Associates Embedded (Poky/Yocto Powered) Extensible SDK installer
> version 2.2+snapshot
> ===========================================================================

Ah, I see what's going wrong here - we're doing a sed replacement and the 
ampersand is being interpreted as an "insert matched string" directive - my 
fault. I'll insert some escaping.

> The second is that I use my own distribution (not poky).  How can I
> build an eSDK using my distribution?

FYI the eSDK will use whatever you set in DISTRO - you have your own 
distribution, but I assume you are still referencing poky - perhaps as an 
include from your distro configuration? At least meta-poky must be in your 
bblayers.conf, otherwise I don't think you'd be getting this error.

Regardless of that, there is a bug here somewhere. What do you have under 
layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?

> Once I ran into this error, I tried rebuilding using the [old] SDK.
> I noticed that it seemed to rebuild [most] everything all over again.
> Is there no shared state / reusable components between the eSDK and SDK?

The extensible SDK and standard SDK are quite different - the host part of the 
extensible SDK is built out of -native rather than nativesdk- components 
(aside from buildtools-tarball, that is) so there are lots of things that need 
to be built if you subsequently build the standard SDK and you haven't done so 
already. It shouldn't be "almost everything", but I appreciate it's often hard 
to tell.

> Finally, since I had to install SDK and not eSDK, I'm missing some tools
> I was hoping to have.  I want to build PRU programs for the BeagleBoneBlack
> and I'm using meta-ti to import those tools and programs.  I was expecting
> the PRU tools which come from ti-cgt-pru-native to be included with my
> eSDK/SDK, but they don't seem to be, at least not in the SDK.  How can I
> get these tools available so I can use the SDK to develop PRU code for the
> BBB?

Not sure exactly, but for the standard SDK I would assume you'd need to append
nativesdk-<something> to TOOLCHAIN_HOST_TASK so that those tools get included. 
Aside from the BSP setting that variable (which probably isn't a good idea) 
there isn't currently a means of host tools automatically getting pulled into 
the SDK based on the target, though it has been discussed [1].

Cheers,
Paul

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5429

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: esdk without using Poky?

[Gary Thomas]

On 2016-10-31 23:06, Paul Eggleton wrote:
> Hi Gary,
>
> On Mon, 31 Oct 2016 13:19:18 Gary Thomas wrote:
>> I'm trying to build an extensible SDK (eSDK) for my target and running into
>> a few problems.
>>
>>    gthomas@zeus:~$
>> /work/tmp/mlb-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh MLB
>> @SDK_TITLE@ Associates Embedded (Poky/Yocto Powered) Extensible SDK
>> installer version 2.2+snapshot
>> ===========================================================================
>> Enter target directory for SDK (default:
>> ~/mlb_sdk):
>>    You are about to install the SDK to "/home/gthomas/mlb_sdk".
>> Proceed[Y/n]? y Extracting SDK.........................................done
>>    Setting it up...
>>    Extracting buildtools...
>>    Preparing build system...
>>    Error: 'meta-poky/conf' must be a directory containing local.conf &
>> bblayers.conf
>>
>> The first thing I notice is the banner which should read:
>>    MLB & Associates Embedded (Poky/Yocto Powered) Extensible SDK installer
>> version 2.2+snapshot
>> ===========================================================================
>
> Ah, I see what's going wrong here - we're doing a sed replacement and the
> ampersand is being interpreted as an "insert matched string" directive - my
> fault. I'll insert some escaping.
>
>> The second is that I use my own distribution (not poky).  How can I
>> build an eSDK using my distribution?
>
> FYI the eSDK will use whatever you set in DISTRO - you have your own
> distribution, but I assume you are still referencing poky - perhaps as an
> include from your distro configuration? At least meta-poky must be in your
> bblayers.conf, otherwise I don't think you'd be getting this error.
>
> Regardless of that, there is a bug here somewhere. What do you have under
> layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?

I don't have meta-poky, nor any mention of poky, in any of my layers.
I'm still relying on the poky GIT tree, but that's for historical reasons
(started long before the OE-core split).

Perhaps you could try a build with a different distro (other than poky)
and see what happens?  Or if you can recommend something I could try, I'm
more than happy to give it a go.

>
>> Once I ran into this error, I tried rebuilding using the [old] SDK.
>> I noticed that it seemed to rebuild [most] everything all over again.
>> Is there no shared state / reusable components between the eSDK and SDK?
>
> The extensible SDK and standard SDK are quite different - the host part of the
> extensible SDK is built out of -native rather than nativesdk- components
> (aside from buildtools-tarball, that is) so there are lots of things that need
> to be built if you subsequently build the standard SDK and you haven't done so
> already. It shouldn't be "almost everything", but I appreciate it's often hard
> to tell.

Fair enough and as you say, it's hard to tell what's rustling under the covers :-)

>
>> Finally, since I had to install SDK and not eSDK, I'm missing some tools
>> I was hoping to have.  I want to build PRU programs for the BeagleBoneBlack
>> and I'm using meta-ti to import those tools and programs.  I was expecting
>> the PRU tools which come from ti-cgt-pru-native to be included with my
>> eSDK/SDK, but they don't seem to be, at least not in the SDK.  How can I
>> get these tools available so I can use the SDK to develop PRU code for the
>> BBB?
>
> Not sure exactly, but for the standard SDK I would assume you'd need to append
> nativesdk-<something> to TOOLCHAIN_HOST_TASK so that those tools get included.
> Aside from the BSP setting that variable (which probably isn't a good idea)
> there isn't currently a means of host tools automatically getting pulled into
> the SDK based on the target, though it has been discussed [1].

OK, once I get past the 'meta-poky' issue, I can see what I need to do using
this nativesdk-XXX packaging.

>
> Cheers,
> Paul
>
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=5429
>

Thanks for your help

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Paul Eggleton]

On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
> On 2016-10-31 23:06, Paul Eggleton wrote:
> > FYI the eSDK will use whatever you set in DISTRO - you have your own
> > distribution, but I assume you are still referencing poky - perhaps as an
> > include from your distro configuration? At least meta-poky must be in your
> > bblayers.conf, otherwise I don't think you'd be getting this error.
> > 
> > Regardless of that, there is a bug here somewhere. What do you have under
> > layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?
> 
> I don't have meta-poky, nor any mention of poky, in any of my layers.
> I'm still relying on the poky GIT tree, but that's for historical reasons
> (started long before the OE-core split).

I think that's where the problem lies. You may not realise it, but the 
TEMPLATECONF environment variable is being set simply by using the poky 
repository, since there is a .templateconf directory at its root that sets it 
to "meta-poky/conf" if it isn't already set. This isn't a problem during 
normal operation since meta-poky/conf exists there - you'll just be using 
poky's template local.conf and bblayers.conf rather than any other. When you 
generate the eSDK though, meta-poky won't be copied into the eSDK because that 
layer is not in your bblayers.conf and thus you get the error.

I will have to try and figure a way around this. In the mean time you should 
be able to change the saved value in <builddir>/conf/templateconf.cfg to 
"meta/conf" to work around the issue, but it'll come back if you create a new 
build directory unless you set TEMPLATECONF in the external environment before 
running oe-init-build-env.

You're right in your implication that I hadn't tested this - I had tested 
alternative distros with the oe-core repo but not with the poky repo, so I 
hadn't encountered this issue. I've filed a bug [1] to track the issue.

Cheers,
Paul

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10568

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: esdk without using Poky?

[Gary Thomas]

On 2016-11-01 21:33, Paul Eggleton wrote:
> On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
>> On 2016-10-31 23:06, Paul Eggleton wrote:
>>> FYI the eSDK will use whatever you set in DISTRO - you have your own
>>> distribution, but I assume you are still referencing poky - perhaps as an
>>> include from your distro configuration? At least meta-poky must be in your
>>> bblayers.conf, otherwise I don't think you'd be getting this error.
>>>
>>> Regardless of that, there is a bug here somewhere. What do you have under
>>> layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?
>>
>> I don't have meta-poky, nor any mention of poky, in any of my layers.
>> I'm still relying on the poky GIT tree, but that's for historical reasons
>> (started long before the OE-core split).
>
> I think that's where the problem lies. You may not realise it, but the
> TEMPLATECONF environment variable is being set simply by using the poky
> repository, since there is a .templateconf directory at its root that sets it
> to "meta-poky/conf" if it isn't already set. This isn't a problem during
> normal operation since meta-poky/conf exists there - you'll just be using
> poky's template local.conf and bblayers.conf rather than any other. When you
> generate the eSDK though, meta-poky won't be copied into the eSDK because that
> layer is not in your bblayers.conf and thus you get the error.
>
> I will have to try and figure a way around this. In the mean time you should
> be able to change the saved value in <builddir>/conf/templateconf.cfg to
> "meta/conf" to work around the issue, but it'll come back if you create a new
> build directory unless you set TEMPLATECONF in the external environment before
> running oe-init-build-env.

I'm still confused.  There is no mention of meta-poky, or of the $DISTRO 'poky'
anywhere in my <builddir>/conf:
   gthomas@europa:p8701_2016-10-22$ cat conf/templateconf.cfg
   meta-rainier-am335x-p8701/conf
   gthomas@europa:p8701_2016-10-22$ grep -i poky conf/*
   conf/bblayers.conf:  /local/poky-cutting-edge/meta \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-oe \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-amltd \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-rainier-am335x-p8701 \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-ti \
   conf/bblayers.conf:  /local/poky-cutting-edge/meta-webserver \


>
> You're right in your implication that I hadn't tested this - I had tested
> alternative distros with the oe-core repo but not with the poky repo, so I
> hadn't encountered this issue. I've filed a bug [1] to track the issue.
>
> Cheers,
> Paul
>
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=10568
>

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Paul Eggleton]

On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:
> On 2016-11-01 21:33, Paul Eggleton wrote:
> > On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
> >> On 2016-10-31 23:06, Paul Eggleton wrote:
> >>> FYI the eSDK will use whatever you set in DISTRO - you have your own
> >>> distribution, but I assume you are still referencing poky - perhaps as
> >>> an
> >>> include from your distro configuration? At least meta-poky must be in
> >>> your
> >>> bblayers.conf, otherwise I don't think you'd be getting this error.
> >>> 
> >>> Regardless of that, there is a bug here somewhere. What do you have
> >>> under
> >>> layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?
> >> 
> >> I don't have meta-poky, nor any mention of poky, in any of my layers.
> >> I'm still relying on the poky GIT tree, but that's for historical reasons
> >> (started long before the OE-core split).
> > 
> > I think that's where the problem lies. You may not realise it, but the
> > TEMPLATECONF environment variable is being set simply by using the poky
> > repository, since there is a .templateconf directory at its root that sets
> > it to "meta-poky/conf" if it isn't already set. This isn't a problem
> > during normal operation since meta-poky/conf exists there - you'll just
> > be using poky's template local.conf and bblayers.conf rather than any
> > other. When you generate the eSDK though, meta-poky won't be copied into
> > the eSDK because that layer is not in your bblayers.conf and thus you get
> > the error.
> > 
> > I will have to try and figure a way around this. In the mean time you
> > should be able to change the saved value in
> > <builddir>/conf/templateconf.cfg to "meta/conf" to work around the issue,
> > but it'll come back if you create a new build directory unless you set
> > TEMPLATECONF in the external environment before running
> > oe-init-build-env.
> 
> I'm still confused.  There is no mention of meta-poky, or of the $DISTRO
> 'poky' anywhere in my <builddir>/conf:
>    gthomas@europa:p8701_2016-10-22$ cat conf/templateconf.cfg
>    meta-rainier-am335x-p8701/conf
>    gthomas@europa:p8701_2016-10-22$ grep -i poky conf/*
>    conf/bblayers.conf:  /local/poky-cutting-edge/meta \
>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-oe \
>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-amltd \
>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-rainier-am335x-p8701 \
> conf/bblayers.conf:  /local/poky-cutting-edge/meta-ti \
>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-webserver \

It turns out I was mistaken. The templateconf.cfg in your build directory has 
no bearing on what the value ends up being in the eSDK because that file isn't 
copied over - instead it is created from scratch. I am working on a proper fix 
now.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: esdk without using Poky?

[Gary Thomas]

On 2016-11-02 02:44, Paul Eggleton wrote:
> On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:
>> On 2016-11-01 21:33, Paul Eggleton wrote:
>>> On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
>>>> On 2016-10-31 23:06, Paul Eggleton wrote:
>>>>> FYI the eSDK will use whatever you set in DISTRO - you have your own
>>>>> distribution, but I assume you are still referencing poky - perhaps as
>>>>> an
>>>>> include from your distro configuration? At least meta-poky must be in
>>>>> your
>>>>> bblayers.conf, otherwise I don't think you'd be getting this error.
>>>>>
>>>>> Regardless of that, there is a bug here somewhere. What do you have
>>>>> under
>>>>> layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?
>>>>
>>>> I don't have meta-poky, nor any mention of poky, in any of my layers.
>>>> I'm still relying on the poky GIT tree, but that's for historical reasons
>>>> (started long before the OE-core split).
>>>
>>> I think that's where the problem lies. You may not realise it, but the
>>> TEMPLATECONF environment variable is being set simply by using the poky
>>> repository, since there is a .templateconf directory at its root that sets
>>> it to "meta-poky/conf" if it isn't already set. This isn't a problem
>>> during normal operation since meta-poky/conf exists there - you'll just
>>> be using poky's template local.conf and bblayers.conf rather than any
>>> other. When you generate the eSDK though, meta-poky won't be copied into
>>> the eSDK because that layer is not in your bblayers.conf and thus you get
>>> the error.
>>>
>>> I will have to try and figure a way around this. In the mean time you
>>> should be able to change the saved value in
>>> <builddir>/conf/templateconf.cfg to "meta/conf" to work around the issue,
>>> but it'll come back if you create a new build directory unless you set
>>> TEMPLATECONF in the external environment before running
>>> oe-init-build-env.
>>
>> I'm still confused.  There is no mention of meta-poky, or of the $DISTRO
>> 'poky' anywhere in my <builddir>/conf:
>>    gthomas@europa:p8701_2016-10-22$ cat conf/templateconf.cfg
>>    meta-rainier-am335x-p8701/conf
>>    gthomas@europa:p8701_2016-10-22$ grep -i poky conf/*
>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta \
>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-oe \
>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-amltd \
>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-rainier-am335x-p8701 \
>> conf/bblayers.conf:  /local/poky-cutting-edge/meta-ti \
>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-webserver \
>
> It turns out I was mistaken. The templateconf.cfg in your build directory has
> no bearing on what the value ends up being in the eSDK because that file isn't
> copied over - instead it is created from scratch. I am working on a proper fix
> now.

Thanks.  I tried overriding this on the machine where I want to
install the eSDK (not the same as where I built it) like this:
   gthomas@zeus:~$ TEMPLATECONF=meta-rainier-am335x-p8701/conf 
/work/tmp/amltd-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh

Sadly, it still failed the same way.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Paul Eggleton]

On Wed, 02 Nov 2016 03:02:11 Gary Thomas wrote:
> On 2016-11-02 02:44, Paul Eggleton wrote:
> > On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:
> >> On 2016-11-01 21:33, Paul Eggleton wrote:
> >>> On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
> >>>> On 2016-10-31 23:06, Paul Eggleton wrote:
> >>>>> FYI the eSDK will use whatever you set in DISTRO - you have your own
> >>>>> distribution, but I assume you are still referencing poky - perhaps as
> >>>>> an
> >>>>> include from your distro configuration? At least meta-poky must be in
> >>>>> your
> >>>>> bblayers.conf, otherwise I don't think you'd be getting this error.
> >>>>> 
> >>>>> Regardless of that, there is a bug here somewhere. What do you have
> >>>>> under
> >>>>> layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?
> >>>> 
> >>>> I don't have meta-poky, nor any mention of poky, in any of my layers.
> >>>> I'm still relying on the poky GIT tree, but that's for historical
> >>>> reasons
> >>>> (started long before the OE-core split).
> >>> 
> >>> I think that's where the problem lies. You may not realise it, but the
> >>> TEMPLATECONF environment variable is being set simply by using the poky
> >>> repository, since there is a .templateconf directory at its root that
> >>> sets
> >>> it to "meta-poky/conf" if it isn't already set. This isn't a problem
> >>> during normal operation since meta-poky/conf exists there - you'll just
> >>> be using poky's template local.conf and bblayers.conf rather than any
> >>> other. When you generate the eSDK though, meta-poky won't be copied into
> >>> the eSDK because that layer is not in your bblayers.conf and thus you
> >>> get
> >>> the error.
> >>> 
> >>> I will have to try and figure a way around this. In the mean time you
> >>> should be able to change the saved value in
> >>> <builddir>/conf/templateconf.cfg to "meta/conf" to work around the
> >>> issue,
> >>> but it'll come back if you create a new build directory unless you set
> >>> TEMPLATECONF in the external environment before running
> >>> oe-init-build-env.
> >> 
> >> I'm still confused.  There is no mention of meta-poky, or of the $DISTRO
> >> 
> >> 'poky' anywhere in my <builddir>/conf:
> >>    gthomas@europa:p8701_2016-10-22$ cat conf/templateconf.cfg
> >>    meta-rainier-am335x-p8701/conf
> >>    gthomas@europa:p8701_2016-10-22$ grep -i poky conf/*
> >>    conf/bblayers.conf:  /local/poky-cutting-edge/meta \
> >>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-oe \
> >>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-amltd \
> >>    conf/bblayers.conf: 
> >>    /local/poky-cutting-edge/meta-rainier-am335x-p8701 \
> >> 
> >> conf/bblayers.conf:  /local/poky-cutting-edge/meta-ti \
> >> 
> >>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-webserver \
> > 
> > It turns out I was mistaken. The templateconf.cfg in your build directory
> > has no bearing on what the value ends up being in the eSDK because that
> > file isn't copied over - instead it is created from scratch. I am working
> > on a proper fix now.
> 
> Thanks.  I tried overriding this on the machine where I want to
> install the eSDK (not the same as where I built it) like this:
>    gthomas@zeus:~$ TEMPLATECONF=meta-rainier-am335x-p8701/conf
> /work/tmp/amltd-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh
> 
> Sadly, it still failed the same way.

Right, that's because the environment is filtered by the SDK installer, so 
that won't make it through into the environment used during installation.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: esdk without using Poky?

[Gary Thomas]

On 2016-11-02 03:25, Paul Eggleton wrote:
> On Wed, 02 Nov 2016 03:02:11 Gary Thomas wrote:
>> On 2016-11-02 02:44, Paul Eggleton wrote:
>>> On Wed, 02 Nov 2016 02:37:57 Gary Thomas wrote:
>>>> On 2016-11-01 21:33, Paul Eggleton wrote:
>>>>> On Tue, 01 Nov 2016 13:36:57 Gary Thomas wrote:
>>>>>> On 2016-10-31 23:06, Paul Eggleton wrote:
>>>>>>> FYI the eSDK will use whatever you set in DISTRO - you have your own
>>>>>>> distribution, but I assume you are still referencing poky - perhaps as
>>>>>>> an
>>>>>>> include from your distro configuration? At least meta-poky must be in
>>>>>>> your
>>>>>>> bblayers.conf, otherwise I don't think you'd be getting this error.
>>>>>>>
>>>>>>> Regardless of that, there is a bug here somewhere. What do you have
>>>>>>> under
>>>>>>> layers/ in the generated SDK? Are you setting TEMPLATECONF anywhere?
>>>>>>
>>>>>> I don't have meta-poky, nor any mention of poky, in any of my layers.
>>>>>> I'm still relying on the poky GIT tree, but that's for historical
>>>>>> reasons
>>>>>> (started long before the OE-core split).
>>>>>
>>>>> I think that's where the problem lies. You may not realise it, but the
>>>>> TEMPLATECONF environment variable is being set simply by using the poky
>>>>> repository, since there is a .templateconf directory at its root that
>>>>> sets
>>>>> it to "meta-poky/conf" if it isn't already set. This isn't a problem
>>>>> during normal operation since meta-poky/conf exists there - you'll just
>>>>> be using poky's template local.conf and bblayers.conf rather than any
>>>>> other. When you generate the eSDK though, meta-poky won't be copied into
>>>>> the eSDK because that layer is not in your bblayers.conf and thus you
>>>>> get
>>>>> the error.
>>>>>
>>>>> I will have to try and figure a way around this. In the mean time you
>>>>> should be able to change the saved value in
>>>>> <builddir>/conf/templateconf.cfg to "meta/conf" to work around the
>>>>> issue,
>>>>> but it'll come back if you create a new build directory unless you set
>>>>> TEMPLATECONF in the external environment before running
>>>>> oe-init-build-env.
>>>>
>>>> I'm still confused.  There is no mention of meta-poky, or of the $DISTRO
>>>>
>>>> 'poky' anywhere in my <builddir>/conf:
>>>>    gthomas@europa:p8701_2016-10-22$ cat conf/templateconf.cfg
>>>>    meta-rainier-am335x-p8701/conf
>>>>    gthomas@europa:p8701_2016-10-22$ grep -i poky conf/*
>>>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta \
>>>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-oe \
>>>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-amltd \
>>>>    conf/bblayers.conf:
>>>>    /local/poky-cutting-edge/meta-rainier-am335x-p8701 \
>>>>
>>>> conf/bblayers.conf:  /local/poky-cutting-edge/meta-ti \
>>>>
>>>>    conf/bblayers.conf:  /local/poky-cutting-edge/meta-webserver \
>>>
>>> It turns out I was mistaken. The templateconf.cfg in your build directory
>>> has no bearing on what the value ends up being in the eSDK because that
>>> file isn't copied over - instead it is created from scratch. I am working
>>> on a proper fix now.
>>
>> Thanks.  I tried overriding this on the machine where I want to
>> install the eSDK (not the same as where I built it) like this:
>>    gthomas@zeus:~$ TEMPLATECONF=meta-rainier-am335x-p8701/conf
>> /work/tmp/amltd-glibc-x86_64-arm-toolchain-ext-2.2+snapshot.sh
>>
>> Sadly, it still failed the same way.
>
> Right, that's because the environment is filtered by the SDK installer, so
> that won't make it through into the environment used during installation.

I've tested your patches for this (from the OE-core mailing list)
and I can now build and use the eSDK for my board :-)

I do have a couple observations/questions:

* I added my missing tool with this line in my local.conf
      TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
   Why did this cause many of the nativesdk tools to have to be rebuilt?
      NOTE: Tasks Summary: Attempted 2423 tasks of which 2043 didn't need to be rerun and all succeeded.

* When I built 'nativesdk-ti-cgt-pru', I got a number of scary looking errors - here are a few:
     ERROR: nativesdk-ti-cgt-pru-2.1.1-r0 do_configure: Taskhash mismatch eb0229a8c364c4c399fc2e84f4dfaf91 versus 
b5d16aa43836f3832200af39aba5b796 for 
virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb.do_configure
     ERROR: Taskhash mismatch eb0229a8c364c4c399fc2e84f4dfaf91 versus b5d16aa43836f3832200af39aba5b796 for 
virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb.do_configure
     ERROR: nativesdk-ti-cgt-pru-2.1.1-r0 do_compile: Taskhash mismatch bc0d6bb3a62f58875962d4ccf1b60dd9 versus 
9e207a5a6aa53512135b5ea3a0610bf3 for 
virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb.do_compile

* When I installed the eSDK on a machine other than where I
   built it, I also got a lot (865) of messages like these:

WARNING: The quilt-native:do_configure sig is computed to be 315b89079a159e1d4e43d3199c487bdb, but the sig is locked to 
a9909bdcc4c81106eb42c21bb0d760fc in SIGGEN_LOCKEDSIGS_t-x86-64
The quilt-native:do_compile sig is computed to be be128011cc1f47157898f513dc4e9bbb, but the sig is locked to 
fa83446de41fe9e7c2c49c2745438a8d in SIGGEN_LOCKEDSIGS_t-x86-64
The quilt-native:do_install sig is computed to be 85c8be820a93b84901dd7528eb61840e, but the sig is locked to 
6caa366055ef06147ef64cbe7d83c608 in SIGGEN_LOCKEDSIGS_t-x86-64
The quilt-native:do_populate_sysroot sig is computed to be 5b0f52254aa8548fa406b806dae000cb, but the sig is locked to 
d3cf7e526716d0286ce596c44c6b9936 in SIGGEN_LOCKEDSIGS_t-x86-64
The glibc:do_patch sig is computed to be 373272e62465460928320aa7643f9916, but the sig is locked to 
712620a3943887e11d9730013d1e07f0 in SIGGEN_LOCKEDSIGS_t-armv7ahf-neon

All that said, it is now working for me, time to learn to use it!
Thanks for your help.  Feel free to add my Acked-by or Signed-off-by
to your patches if you wish.

Acked-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Gary Thomas <gary@mlbassoc.com>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Paul Eggleton]

On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
> I've tested your patches for this (from the OE-core mailing list)
> and I can now build and use the eSDK for my board :-)

Great!
 
> I do have a couple observations/questions:
> 
> * I added my missing tool with this line in my local.conf
>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
>    Why did this cause many of the nativesdk tools to have to be rebuilt?

So just FYI this will only work for the standard SDK, it's not the right way 
to add these tools for the eSDK - in fact it may break the eSDK due to 
bringing things into the native sysroot that shouldn't be there.

At the moment I think the only way to properly add this to the eSDK is to do 
this:

SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"

We don't document this, and it's a little awkward in any case. I'll work on 
it.

> * When I built 'nativesdk-ti-cgt-pru', I got a number of scary looking
> errors - here are a few: ERROR: nativesdk-ti-cgt-pru-2.1.1-r0 do_configure:
> Taskhash mismatch eb0229a8c364c4c399fc2e84f4dfaf91 versus
> b5d16aa43836f3832200af39aba5b796 for
> virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cg
> t-pru_2.1.1.bb.do_configure ERROR: Taskhash mismatch
> eb0229a8c364c4c399fc2e84f4dfaf91 versus b5d16aa43836f3832200af39aba5b796
> for
> virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-c
> gt-pru_2.1.1.bb.do_configure ERROR: nativesdk-ti-cgt-pru-2.1.1-r0
> do_compile: Taskhash mismatch bc0d6bb3a62f58875962d4ccf1b60dd9 versus
> 9e207a5a6aa53512135b5ea3a0610bf3 for
> virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cg
> t-pru_2.1.1.bb.do_compile

Where did you build this? Just in your normal build?

This kind of error indicates that a variable value is changing while bitbake 
is running - often this is caused by date/time values in variables. Looking in 
meta-ti I can't see anything that would cause this though. Was it only showing 
up for nativesdk-ti-cgt-pru ?

> * When I installed the eSDK on a machine other than where I
>    built it, I also got a lot (865) of messages like these:
> 
> WARNING: The quilt-native:do_configure sig is computed to be
> 315b89079a159e1d4e43d3199c487bdb, but the sig is locked to
> a9909bdcc4c81106eb42c21bb0d760fc in SIGGEN_LOCKEDSIGS_t-x86-64
> The quilt-native:do_compile sig is computed to be
> be128011cc1f47157898f513dc4e9bbb, but the sig is locked to
> fa83446de41fe9e7c2c49c2745438a8d in SIGGEN_LOCKEDSIGS_t-x86-64
> The quilt-native:do_install sig is computed to be
> 85c8be820a93b84901dd7528eb61840e, but the sig is locked to
> 6caa366055ef06147ef64cbe7d83c608 in SIGGEN_LOCKEDSIGS_t-x86-64
> The quilt-native:do_populate_sysroot sig is computed to be
> 5b0f52254aa8548fa406b806dae000cb, but the sig is locked to
> d3cf7e526716d0286ce596c44c6b9936 in SIGGEN_LOCKEDSIGS_t-x86-64
> The glibc:do_patch sig is computed to be 373272e62465460928320aa7643f9916,
> but the sig is locked to 712620a3943887e11d9730013d1e07f0 in
> SIGGEN_LOCKEDSIGS_t-armv7ahf-neon

Right. Are you using uninative? If not, you probably should (and I just sent a 
patch to disable building the eSDK without it).

> All that said, it is now working for me, time to learn to use it!
> Thanks for your help.  Feel free to add my Acked-by or Signed-off-by
> to your patches if you wish.
> 
> Acked-by: Gary Thomas <gary@mlbassoc.com>
> Signed-off-by: Gary Thomas <gary@mlbassoc.com>

Thanks!

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: esdk without using Poky?

[Gary Thomas]

On 2016-11-04 04:41, Paul Eggleton wrote:
> On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
>> I've tested your patches for this (from the OE-core mailing list)
>> and I can now build and use the eSDK for my board :-)
>
> Great!
>
>> I do have a couple observations/questions:
>>
>> * I added my missing tool with this line in my local.conf
>>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
>>    Why did this cause many of the nativesdk tools to have to be rebuilt?
>
> So just FYI this will only work for the standard SDK, it's not the right way
> to add these tools for the eSDK - in fact it may break the eSDK due to
> bringing things into the native sysroot that shouldn't be there.
>
> At the moment I think the only way to properly add this to the eSDK is to do
> this:
>
> SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"
>
> We don't document this, and it's a little awkward in any case. I'll work on
> it.

I'll change my setup to use this.  Hopefully you can find a prettier way to
do it in the future and document how.

>
>> * When I built 'nativesdk-ti-cgt-pru', I got a number of scary looking
>> errors - here are a few: ERROR: nativesdk-ti-cgt-pru-2.1.1-r0 do_configure:
>> Taskhash mismatch eb0229a8c364c4c399fc2e84f4dfaf91 versus
>> b5d16aa43836f3832200af39aba5b796 for
>> virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cg
>> t-pru_2.1.1.bb.do_configure ERROR: Taskhash mismatch
>> eb0229a8c364c4c399fc2e84f4dfaf91 versus b5d16aa43836f3832200af39aba5b796
>> for
>> virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-c
>> gt-pru_2.1.1.bb.do_configure ERROR: nativesdk-ti-cgt-pru-2.1.1-r0
>> do_compile: Taskhash mismatch bc0d6bb3a62f58875962d4ccf1b60dd9 versus
>> 9e207a5a6aa53512135b5ea3a0610bf3 for
>> virtual:nativesdk:/local/poky-cutting-edge/meta-ti/recipes-ti/devtools/ti-cg
>> t-pru_2.1.1.bb.do_compile
>
> Where did you build this? Just in your normal build?

I got this when I built nativesdk-ti-cgt-pru directly from the command line.
The ti-cgt-pru-native package had already been built indirectly by pru-icss.

>
> This kind of error indicates that a variable value is changing while bitbake
> is running - often this is caused by date/time values in variables. Looking in
> meta-ti I can't see anything that would cause this though. Was it only showing
> up for nativesdk-ti-cgt-pru ?
>
>> * When I installed the eSDK on a machine other than where I
>>    built it, I also got a lot (865) of messages like these:
>>
>> WARNING: The quilt-native:do_configure sig is computed to be
>> 315b89079a159e1d4e43d3199c487bdb, but the sig is locked to
>> a9909bdcc4c81106eb42c21bb0d760fc in SIGGEN_LOCKEDSIGS_t-x86-64
>> The quilt-native:do_compile sig is computed to be
>> be128011cc1f47157898f513dc4e9bbb, but the sig is locked to
>> fa83446de41fe9e7c2c49c2745438a8d in SIGGEN_LOCKEDSIGS_t-x86-64
>> The quilt-native:do_install sig is computed to be
>> 85c8be820a93b84901dd7528eb61840e, but the sig is locked to
>> 6caa366055ef06147ef64cbe7d83c608 in SIGGEN_LOCKEDSIGS_t-x86-64
>> The quilt-native:do_populate_sysroot sig is computed to be
>> 5b0f52254aa8548fa406b806dae000cb, but the sig is locked to
>> d3cf7e526716d0286ce596c44c6b9936 in SIGGEN_LOCKEDSIGS_t-x86-64
>> The glibc:do_patch sig is computed to be 373272e62465460928320aa7643f9916,
>> but the sig is locked to 712620a3943887e11d9730013d1e07f0 in
>> SIGGEN_LOCKEDSIGS_t-armv7ahf-neon
>
> Right. Are you using uninative? If not, you probably should (and I just sent a
> patch to disable building the eSDK without it).

I'll give that a go and see if it helps.

>
>> All that said, it is now working for me, time to learn to use it!
>> Thanks for your help.  Feel free to add my Acked-by or Signed-off-by
>> to your patches if you wish.
>>
>> Acked-by: Gary Thomas <gary@mlbassoc.com>
>> Signed-off-by: Gary Thomas <gary@mlbassoc.com>
>
> Thanks!
>
> Cheers,
> Paul
>


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Gary Thomas]

On 2016-11-04 04:41, Paul Eggleton wrote:
> On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
>> I've tested your patches for this (from the OE-core mailing list)
>> and I can now build and use the eSDK for my board :-)
>
> Great!
>
>> I do have a couple observations/questions:
>>
>> * I added my missing tool with this line in my local.conf
>>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
>>    Why did this cause many of the nativesdk tools to have to be rebuilt?
>
> So just FYI this will only work for the standard SDK, it's not the right way
> to add these tools for the eSDK - in fact it may break the eSDK due to
> bringing things into the native sysroot that shouldn't be there.
>
> At the moment I think the only way to properly add this to the eSDK is to do
> this:
>
> SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"
>
> We don't document this, and it's a little awkward in any case. I'll work on
> it.

This was working great for me until I just upgraded to the latest [poky]
master (rev dbb247cac5fbf7b037e4955f9793828451723924).  With the SDK_TARGETS
line in my local.conf, I get this error:

ERROR: Error for /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magicard-demo-image_1.0.bb, 
dependency ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot does not contain exactly one ':' character.
  Task 'rdepends' should be specified in the form 'packagename:task'

Any ideas what changed and how I get it working again?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Patrick Ohly]

On Wed, 2017-01-04 at 12:05 +0100, Gary Thomas wrote:
> On 2016-11-04 04:41, Paul Eggleton wrote:
> > On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
> >> I've tested your patches for this (from the OE-core mailing list)
> >> and I can now build and use the eSDK for my board :-)
> >
> > Great!
> >
> >> I do have a couple observations/questions:
> >>
> >> * I added my missing tool with this line in my local.conf
> >>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
> >>    Why did this cause many of the nativesdk tools to have to be rebuilt?
> >
> > So just FYI this will only work for the standard SDK, it's not the right way
> > to add these tools for the eSDK - in fact it may break the eSDK due to
> > bringing things into the native sysroot that shouldn't be there.
> >
> > At the moment I think the only way to properly add this to the eSDK is to do
> > this:
> >
> > SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"
> >
> > We don't document this, and it's a little awkward in any case. I'll work on
> > it.
> 
> This was working great for me until I just upgraded to the latest [poky]
> master (rev dbb247cac5fbf7b037e4955f9793828451723924).  With the SDK_TARGETS
> line in my local.conf, I get this error:
> 
> ERROR: Error for /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magicard-demo-image_1.0.bb, 
> dependency ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>  does not contain exactly one ':' character.
>   Task 'rdepends' should be specified in the form 'packagename:task'
> 
> Any ideas what changed and how I get it working again?

I enhanced the error checking, and the rdepends varflag in your example
indeed isn't valid. ":do_populate_sysroot" got appended twice to the
recipe name. That error got ignored silently earlier.

populate_sdk_ext.bbclass appends ":do_populate_sysroot" when setting
do_sdk_depends[rdepends], so you should use just:

   SDK_TARGETS += "ti-cgt-pru-native"

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: esdk without using Poky?

[Gary Thomas]

On 2017-01-04 13:54, Patrick Ohly wrote:
> On Wed, 2017-01-04 at 12:05 +0100, Gary Thomas wrote:
>> On 2016-11-04 04:41, Paul Eggleton wrote:
>>> On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
>>>> I've tested your patches for this (from the OE-core mailing list)
>>>> and I can now build and use the eSDK for my board :-)
>>>
>>> Great!
>>>
>>>> I do have a couple observations/questions:
>>>>
>>>> * I added my missing tool with this line in my local.conf
>>>>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
>>>>    Why did this cause many of the nativesdk tools to have to be rebuilt?
>>>
>>> So just FYI this will only work for the standard SDK, it's not the right way
>>> to add these tools for the eSDK - in fact it may break the eSDK due to
>>> bringing things into the native sysroot that shouldn't be there.
>>>
>>> At the moment I think the only way to properly add this to the eSDK is to do
>>> this:
>>>
>>> SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"
>>>
>>> We don't document this, and it's a little awkward in any case. I'll work on
>>> it.
>>
>> This was working great for me until I just upgraded to the latest [poky]
>> master (rev dbb247cac5fbf7b037e4955f9793828451723924).  With the SDK_TARGETS
>> line in my local.conf, I get this error:
>>
>> ERROR: Error for /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magicard-demo-image_1.0.bb,
>> dependency ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>>  does not contain exactly one ':' character.
>>   Task 'rdepends' should be specified in the form 'packagename:task'
>>
>> Any ideas what changed and how I get it working again?
>
> I enhanced the error checking, and the rdepends varflag in your example
> indeed isn't valid. ":do_populate_sysroot" got appended twice to the
> recipe name. That error got ignored silently earlier.
>
> populate_sdk_ext.bbclass appends ":do_populate_sysroot" when setting
> do_sdk_depends[rdepends], so you should use just:
>
>    SDK_TARGETS += "ti-cgt-pru-native"
>

Thanks that worked - at least I can build, I haven't checked the esdk yet.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Gary Thomas]

On 2017-01-04 14:25, Gary Thomas wrote:
> On 2017-01-04 13:54, Patrick Ohly wrote:
>> On Wed, 2017-01-04 at 12:05 +0100, Gary Thomas wrote:
>>> On 2016-11-04 04:41, Paul Eggleton wrote:
>>>> On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
>>>>> I've tested your patches for this (from the OE-core mailing list)
>>>>> and I can now build and use the eSDK for my board :-)
>>>>
>>>> Great!
>>>>
>>>>> I do have a couple observations/questions:
>>>>>
>>>>> * I added my missing tool with this line in my local.conf
>>>>>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
>>>>>    Why did this cause many of the nativesdk tools to have to be rebuilt?
>>>>
>>>> So just FYI this will only work for the standard SDK, it's not the right way
>>>> to add these tools for the eSDK - in fact it may break the eSDK due to
>>>> bringing things into the native sysroot that shouldn't be there.
>>>>
>>>> At the moment I think the only way to properly add this to the eSDK is to do
>>>> this:
>>>>
>>>> SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"
>>>>
>>>> We don't document this, and it's a little awkward in any case. I'll work on
>>>> it.
>>>
>>> This was working great for me until I just upgraded to the latest [poky]
>>> master (rev dbb247cac5fbf7b037e4955f9793828451723924).  With the SDK_TARGETS
>>> line in my local.conf, I get this error:
>>>
>>> ERROR: Error for /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magicard-demo-image_1.0.bb,
>>> dependency ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot
>>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>>  does not contain exactly one ':' character.
>>>   Task 'rdepends' should be specified in the form 'packagename:task'
>>>
>>> Any ideas what changed and how I get it working again?
>>
>> I enhanced the error checking, and the rdepends varflag in your example
>> indeed isn't valid. ":do_populate_sysroot" got appended twice to the
>> recipe name. That error got ignored silently earlier.
>>
>> populate_sdk_ext.bbclass appends ":do_populate_sysroot" when setting
>> do_sdk_depends[rdepends], so you should use just:
>>
>>    SDK_TARGETS += "ti-cgt-pru-native"
>>
>
> Thanks that worked - at least I can build, I haven't checked the esdk yet.
>

Sadly, this is broken once again.  I just upgraded my Poky/Yocto
to rev d45d4a5a21ab4209b87331dddf515ecdb62367fa and if I have the
   SDK_TARGETS += "ti-cgt-pru-native"
in my local.conf, I get this hard error:

ERROR: Task do_sdk_depends in 
/home/gary/tmp/p8701_2017-01-31/opt/amltd/poky/meta-rainier-am335x-p8701/packages/images/installer-image.bb rdepends 
upon non-existent task do_package_write_ipk in 
virtual:native:/home/gary/tmp/p8701_2017-01-31/opt/amltd/poky/meta-ti/recipes-ti/devtools/ti-cgt-pru_2.1.1.bb
ERROR: Command execution failed: 1

Any ideas how to proceed?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: esdk without using Poky?

[Paul Eggleton]

On Tuesday, 31 January 2017 8:09:01 AM NZDT Gary Thomas wrote:
> On 2017-01-04 14:25, Gary Thomas wrote:
> > On 2017-01-04 13:54, Patrick Ohly wrote:
> >> On Wed, 2017-01-04 at 12:05 +0100, Gary Thomas wrote:
> >>> On 2016-11-04 04:41, Paul Eggleton wrote:
> >>>> On Wed, 02 Nov 2016 07:25:13 Gary Thomas wrote:
> >>>>> I've tested your patches for this (from the OE-core mailing list)
> >>>>> and I can now build and use the eSDK for my board :-)
> >>>> 
> >>>> Great!
> >>>> 
> >>>>> I do have a couple observations/questions:
> >>>>> 
> >>>>> * I added my missing tool with this line in my local.conf
> >>>>> 
> >>>>>       TOOLCHAIN_HOST_TASK_append = " nativesdk-ti-cgt-pru"
> >>>>>    
> >>>>>    Why did this cause many of the nativesdk tools to have to be
> >>>>>    rebuilt?
> >>>> 
> >>>> So just FYI this will only work for the standard SDK, it's not the
> >>>> right way to add these tools for the eSDK - in fact it may break the
> >>>> eSDK due to bringing things into the native sysroot that shouldn't be
> >>>> there.
> >>>> 
> >>>> At the moment I think the only way to properly add this to the eSDK is
> >>>> to do this:
> >>>> 
> >>>> SDK_TARGETS += "ti-cgt-pru-native:do_populate_sysroot"
> >>>> 
> >>>> We don't document this, and it's a little awkward in any case. I'll
> >>>> work on
> >>>> it.
> >>> 
> >>> This was working great for me until I just upgraded to the latest [poky]
> >>> master (rev dbb247cac5fbf7b037e4955f9793828451723924).  With the
> >>> SDK_TARGETS line in my local.conf, I get this error:
> >>> 
> >>> ERROR: Error for
> >>> /local/poky-cutting-edge/meta-rainier-am335x-p8701/packages/images/magi
> >>> card-demo-image_1.0.bb, dependency
> >>> ti-cgt-pru-native:do_populate_sysroot:do_populate_sysroot>>> 
> >>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>  
> >>>  does not contain exactly one ':' character.
> >>>  
> >>>   Task 'rdepends' should be specified in the form 'packagename:task'
> >>> 
> >>> Any ideas what changed and how I get it working again?
> >> 
> >> I enhanced the error checking, and the rdepends varflag in your example
> >> indeed isn't valid. ":do_populate_sysroot" got appended twice to the
> >> recipe name. That error got ignored silently earlier.
> >> 
> >> populate_sdk_ext.bbclass appends ":do_populate_sysroot" when setting
> >> 
> >> do_sdk_depends[rdepends], so you should use just:
> >>    SDK_TARGETS += "ti-cgt-pru-native"
> > 
> > Thanks that worked - at least I can build, I haven't checked the esdk yet.
> 
> Sadly, this is broken once again.  I just upgraded my Poky/Yocto
> to rev d45d4a5a21ab4209b87331dddf515ecdb62367fa and if I have the
>    SDK_TARGETS += "ti-cgt-pru-native"
> in my local.conf, I get this hard error:
> 
> ERROR: Task do_sdk_depends in
> /home/gary/tmp/p8701_2017-01-31/opt/amltd/poky/meta-rainier-am335x-p8701/pac
> kages/images/installer-image.bb rdepends upon non-existent task
> do_package_write_ipk in
> virtual:native:/home/gary/tmp/p8701_2017-01-31/opt/amltd/poky/meta-ti/recipe
> s-ti/devtools/ti-cgt-pru_2.1.1.bb ERROR: Command execution failed: 1
> 
> Any ideas how to proceed?

Sorry for the delay - I have a fix for this that I'll send out soon (basically 
drop setting SDK_RDEPENDS in populate_sdk_ext.bbclass). I'm not sure what 
happened recently to cause this to come up, but the dependency is erroneous 
and it appears SDK_REPENDS doesn't need to be set anyway.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre