[PATCH 0/1] curl-native build fix

[PATCH 0/1] curl-native build fix

[Qing He]

Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: qhe/fix
  Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=qhe/fix

Thanks,
    Qing He
---


Qing He (1):
  curl: fix native dependency

 meta/recipes-support/curl/curl_7.21.2.bb |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

[PATCH 1/1] curl: fix native dependency

[Qing He]

disable gnutls for -native
also fix --with-gnutls parameter for target

Signed-off-by: Qing He <qing.he@intel.com>
---
 meta/recipes-support/curl/curl_7.21.2.bb |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/curl/curl_7.21.2.bb b/meta/recipes-support/curl/curl_7.21.2.bb
index 1e11222..fd1d5dd 100644
--- a/meta/recipes-support/curl/curl_7.21.2.bb
+++ b/meta/recipes-support/curl/curl_7.21.2.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = "file://COPYING;beginline=7;md5=3a34942f4ae3fbf1a303160714e66
 DEPENDS = "zlib gnutls"
 DEPENDS_virtclass-native = "zlib-native"
 DEPENDS_virtclass-nativesdk = "zlib-nativesdk"
-PR = "r0"
+PR = "r1"
 
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
            file://noldlibpath.patch \
@@ -17,7 +17,6 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
 inherit autotools pkgconfig binconfig
 
 EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
-                --with-gnutls=${STAGING_BINDIR_CROSS}/ \
                 --without-ssl \
                 --without-libssh2 \
 		--with-random=/dev/urandom \
@@ -25,6 +24,10 @@ EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
 		--enable-crypto-auth \
 		"
 
+EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
+EXTRA_OECONF_virtclass-native_append = " --without-gnutls"
+EXTRA_OECONF_virtclass-nativesdk_append = " --without-gnutls"
+
 do_configure_prepend() {
 	sed -i s:OPT_GNUTLS/bin:OPT_GNUTLS:g configure.ac
 }
-- 
1.7.0

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Wed, 2010-11-17 at 16:26 +0800, Qing He wrote:
> @@ -25,6 +24,10 @@ EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
>  		--enable-crypto-auth \
>  		"
>  
> +EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
> +EXTRA_OECONF_virtclass-native_append = " --without-gnutls"
> +EXTRA_OECONF_virtclass-nativesdk_append = " --without-gnutls"
> +
>  do_configure_prepend() {
>  	sed -i s:OPT_GNUTLS/bin:OPT_GNUTLS:g configure.ac
>  }

I'm going to push a fix but I wanted to note that the above is not
correct. Let me walk through this since I expect various people find
this confusing.

EXTRA_OECONF_virtclass-native_append = "X"

means append "X" to the variable EXTRA_OECONF_virtclass-native

So as bitbake expands this, 

EXTRA_OECONF_virtclass-native = "X" (since EXTRA_OECONF_virtclass-native
was empty)

When bitbake expands overrides, the virtclass-native can be removed and
this overwrites the original EXTRA_OECONF variable so EXTRA_OECONF
becomes just X.

Now taking:

EXTRA_OECONF_append_virtclass-native = "X"

This is different. In this case, when overrides are expanded, this
becomes EXTRA_OECONF_append and then X is added to EXTRA_OECONF.

If the virtclass-native is never expanded (not in OVERRIDES), the append
is never "seen" by bitbake.

Unfortunately rewriting the above to:

EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
EXTRA_OECONF_append_virtclass-native = " --without-gnutls"
EXTRA_OECONF_append_virtclass-nativesdk = " --without-gnutls"

doesn't help since we end up with two appends in the native/nativesdk
cases. There is a way out of this though:

+CURLGNUTLS = " --with-gnutls=${STAGING_LIBDIR}/../"
+CURLGNUTLS_virtclass-native = "--without-gnutls"
+CURLGNUTLS_virtclass-nativesdk = "--without-gnutls"

and then reference CURLGNUTLS in EXTRA_OECONF which is what my update
does :)

Cheers,

Richard

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: Richard Purdie
>Sent: Sunday, November 28, 2010 10:23 PM
>
>On Wed, 2010-11-17 at 16:26 +0800, Qing He wrote:
>> @@ -25,6 +24,10 @@ EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
>>  		--enable-crypto-auth \
>>  		"
>>
>> +EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
>> +EXTRA_OECONF_virtclass-native_append = " --without-gnutls"
>> +EXTRA_OECONF_virtclass-nativesdk_append = " --without-gnutls"
>> +
>>  do_configure_prepend() {
>>  	sed -i s:OPT_GNUTLS/bin:OPT_GNUTLS:g configure.ac
>>  }
>
>I'm going to push a fix but I wanted to note that the above is not
>correct. Let me walk through this since I expect various people find
>this confusing.
>
>EXTRA_OECONF_virtclass-native_append = "X"
>
>means append "X" to the variable EXTRA_OECONF_virtclass-native
>
>So as bitbake expands this,
>
>EXTRA_OECONF_virtclass-native = "X" (since EXTRA_OECONF_virtclass-native
>was empty)
>
>When bitbake expands overrides, the virtclass-native can be removed and
>this overwrites the original EXTRA_OECONF variable so EXTRA_OECONF
>becomes just X.

I guess this will not happen, since finalize() first expands override and then
handle append/prepend. In that way virtclass-native has been expanded before
append is handled, and thus finally we'll get a variable EXTRA_OECONF_virtclass-native
which ends up to mean nothing in the database. Is it true?

>
>Now taking:
>
>EXTRA_OECONF_append_virtclass-native = "X"
>
>This is different. In this case, when overrides are expanded, this
>becomes EXTRA_OECONF_append and then X is added to EXTRA_OECONF.
>
>If the virtclass-native is never expanded (not in OVERRIDES), the append
>is never "seen" by bitbake.
>
>Unfortunately rewriting the above to:
>
>EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
>EXTRA_OECONF_append_virtclass-native = " --without-gnutls"
>EXTRA_OECONF_append_virtclass-nativesdk = " --without-gnutls"
>
>doesn't help since we end up with two appends in the native/nativesdk
>cases. There is a way out of this though:

This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
is simply a variable. In that case the expanded value should override the 1st assignment
of EXTRA_OECONF_append, and then we should get:

EXTRA_OECONF_append = " --without-gnutls "

and then that's what we expect.

I guess I may still overlook something here, and really appreciate your explanation
on the whole flow which is helpful. :-)

Thanks
Kevin

>
>+CURLGNUTLS = " --with-gnutls=${STAGING_LIBDIR}/../"
>+CURLGNUTLS_virtclass-native = "--without-gnutls"
>+CURLGNUTLS_virtclass-nativesdk = "--without-gnutls"
>
>and then reference CURLGNUTLS in EXTRA_OECONF which is what my update
>does :)
>
>Cheers,
>
>Richard
>
>_______________________________________________
>poky mailing list
>poky@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/poky

Re: [PATCH 1/1] curl: fix native dependency

[Chris Larson]

On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
> This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
> is simply a variable. In that case the expanded value should override the 1st assignment
> of EXTRA_OECONF_append, and then we should get:
>
> EXTRA_OECONF_append = " --without-gnutls "
>
> and then that's what we expect.
>
> I guess I may still overlook something here, and really appreciate your explanation
> on the whole flow which is helpful. :-)

No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
operations, not part of the name.  The value gets set aside in a list
of appends for that variable.  One _append cannot override/replace
another on the same variable, its always cumulative.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: Chris Larson
>Sent: Monday, November 29, 2010 1:54 PM
>
>On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
>> This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
>> is simply a variable. In that case the expanded value should override the 1st assignment
>> of EXTRA_OECONF_append, and then we should get:
>>
>> EXTRA_OECONF_append = " --without-gnutls "
>>
>> and then that's what we expect.
>>
>> I guess I may still overlook something here, and really appreciate your explanation
>> on the whole flow which is helpful. :-)
>
>No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
>operations, not part of the name.  The value gets set aside in a list
>of appends for that variable.  One _append cannot override/replace
>another on the same variable, its always cumulative.

yes, you're correct. Thanks for pointing it out.

Thanks,
Kevin

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
> On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
> > This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
> > is simply a variable. In that case the expanded value should override the 1st assignment
> > of EXTRA_OECONF_append, and then we should get:
> >
> > EXTRA_OECONF_append = " --without-gnutls "
> >
> > and then that's what we expect.
> >
> > I guess I may still overlook something here, and really appreciate your explanation
> > on the whole flow which is helpful. :-)
> 
> No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
> operations, not part of the name.  The value gets set aside in a list
> of appends for that variable.  One _append cannot override/replace
> another on the same variable, its always cumulative.

Right.

Interestingly though, if I add this to curl*.bb:

FOO = "A"
FOO_append = "B"
FOO_append_virtclass-native = "C"

and then "bitbake curl-native -e | grep FOO" (he recipe has a
BBCLASSEXTEND native) what should I see?

I see FOO = "AB" which is not what I thought it would do...

Cheers,

Richard

Re: [PATCH 1/1] curl: fix native dependency

[Frans Meulenbroeks]

2010/11/29 Richard Purdie <rpurdie@linux.intel.com>:
> On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
>> On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
>> > This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
>> > is simply a variable. In that case the expanded value should override the 1st assignment
>> > of EXTRA_OECONF_append, and then we should get:
>> >
>> > EXTRA_OECONF_append = " --without-gnutls "
>> >
>> > and then that's what we expect.
>> >
>> > I guess I may still overlook something here, and really appreciate your explanation
>> > on the whole flow which is helpful. :-)
>>
>> No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
>> operations, not part of the name.  The value gets set aside in a list
>> of appends for that variable.  One _append cannot override/replace
>> another on the same variable, its always cumulative.
>
> Right.
>
> Interestingly though, if I add this to curl*.bb:
>
> FOO = "A"
> FOO_append = "B"
> FOO_append_virtclass-native = "C"
>
> and then "bitbake curl-native -e | grep FOO" (he recipe has a
> BBCLASSEXTEND native) what should I see?
>
> I see FOO = "AB" which is not what I thought it would do...
>

Hm.
Please allow me the remark that, if this does not do what you as
expert expect it to to, that probably for mere mortals like me, this
is a construct that is way too complicated.

What is the rationale that _append is not a variable? Wouldn't it be
more logical/orthogonal/clearer if it was (and get appended at the end
as most people seem to expect/assume)

Puzzled. Frans

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Mon, 2010-11-29 at 14:04 +0100, Frans Meulenbroeks wrote:
> 2010/11/29 Richard Purdie <rpurdie@linux.intel.com>:
> > Interestingly though, if I add this to curl*.bb:
> >
> > FOO = "A"
> > FOO_append = "B"
> > FOO_append_virtclass-native = "C"
> >
> > and then "bitbake curl-native -e | grep FOO" (he recipe has a
> > BBCLASSEXTEND native) what should I see?
> >
> > I see FOO = "AB" which is not what I thought it would do...
> >
> 
> Hm.
> Please allow me the remark that, if this does not do what you as
> expert expect it to to, that probably for mere mortals like me, this
> is a construct that is way too complicated.

Its not that its too complicated, its just that its not following what
I've understood to be the rules that variables follow. This is probably
a bug in the parser but I'm very careful about jumping to that
conclusion as there could be another explanation, not least the way
virtclass as an override is implemented. I'd be interested in Chris'
opinion which is why I was non-committal in calling it a bug ;-).

> What is the rationale that _append is not a variable? Wouldn't it be
> more logical/orthogonal/clearer if it was (and get appended at the end
> as most people seem to expect/assume)

The point is that appends should stack and this is exactly the same as
normal variable rules, e.g.:

FOO = "A"
FOO += "B"
FOO += "C"

and you'd expect the result to be "A B C", not "A C" which it would be
if += was the append operator did not stack.

Cheers,

Richard

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: Richard Purdie
>Sent: Monday, November 29, 2010 11:17 PM
>
>On Mon, 2010-11-29 at 14:04 +0100, Frans Meulenbroeks wrote:
>> 2010/11/29 Richard Purdie <rpurdie@linux.intel.com>:
>> > Interestingly though, if I add this to curl*.bb:
>> >
>> > FOO = "A"
>> > FOO_append = "B"
>> > FOO_append_virtclass-native = "C"
>> >
>> > and then "bitbake curl-native -e | grep FOO" (he recipe has a
>> > BBCLASSEXTEND native) what should I see?
>> >
>> > I see FOO = "AB" which is not what I thought it would do...
>> >
>>
>> Hm.
>> Please allow me the remark that, if this does not do what you as
>> expert expect it to to, that probably for mere mortals like me, this
>> is a construct that is way too complicated.
>
>Its not that its too complicated, its just that its not following what
>I've understood to be the rules that variables follow. This is probably
>a bug in the parser but I'm very careful about jumping to that
>conclusion as there could be another explanation, not least the way
>virtclass as an override is implemented. I'd be interested in Chris'
>opinion which is why I was non-committal in calling it a bug ;-).
>
>> What is the rationale that _append is not a variable? Wouldn't it be
>> more logical/orthogonal/clearer if it was (and get appended at the end
>> as most people seem to expect/assume)
>
>The point is that appends should stack and this is exactly the same as
>normal variable rules, e.g.:
>
>FOO = "A"
>FOO += "B"
>FOO += "C"
>
>and you'd expect the result to be "A B C", not "A C" which it would be
>if += was the append operator did not stack.
>

then what about:

FOO = "A"
FOO_append = "B"
FOO_append_virtclass-native = "C"

should it be "A C" or "A B C"?

I think I find the problem in current code (sent out in another mail), but the
fix would depend on the answer here. From the current code, it looks designed
for "A C".

Thanks
Kevin

Re: [PATCH 1/1] curl: fix native dependency

[Chris Larson]

On Mon, Nov 29, 2010 at 5:25 AM, Richard Purdie <rpurdie@linux.intel.com> wrote:
> On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
>> On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
>> > This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
>> > is simply a variable. In that case the expanded value should override the 1st assignment
>> > of EXTRA_OECONF_append, and then we should get:
>> >
>> > EXTRA_OECONF_append = " --without-gnutls "
>> >
>> > and then that's what we expect.
>> >
>> > I guess I may still overlook something here, and really appreciate your explanation
>> > on the whole flow which is helpful. :-)
>>
>> No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
>> operations, not part of the name.  The value gets set aside in a list
>> of appends for that variable.  One _append cannot override/replace
>> another on the same variable, its always cumulative.
>
> Right.
>
> Interestingly though, if I add this to curl*.bb:
>
> FOO = "A"
> FOO_append = "B"
> FOO_append_virtclass-native = "C"
>
> and then "bitbake curl-native -e | grep FOO" (he recipe has a
> BBCLASSEXTEND native) what should I see?
>
> I see FOO = "AB" which is not what I thought it would do...

Hmm, this isn't what I'd expect either.  It's certainly not what was
originally intended -- _append_<foo> and _prepend_<foo> were always
supposed to act like normal _append/_prepend, just conditional ones.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: Chris Larson
>Sent: Monday, November 29, 2010 11:25 PM
>
>On Mon, Nov 29, 2010 at 5:25 AM, Richard Purdie <rpurdie@linux.intel.com> wrote:
>> On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
>>> On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
>>> > This also confuses me a bit. When virtclass-native is expanded,
>EXTRA_OECONF_append
>>> > is simply a variable. In that case the expanded value should override the 1st
>assignment
>>> > of EXTRA_OECONF_append, and then we should get:
>>> >
>>> > EXTRA_OECONF_append = " --without-gnutls "
>>> >
>>> > and then that's what we expect.
>>> >
>>> > I guess I may still overlook something here, and really appreciate your explanation
>>> > on the whole flow which is helpful. :-)
>>>
>>> No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
>>> operations, not part of the name.  The value gets set aside in a list
>>> of appends for that variable.  One _append cannot override/replace
>>> another on the same variable, its always cumulative.
>>
>> Right.
>>
>> Interestingly though, if I add this to curl*.bb:
>>
>> FOO = "A"
>> FOO_append = "B"
>> FOO_append_virtclass-native = "C"
>>
>> and then "bitbake curl-native -e | grep FOO" (he recipe has a
>> BBCLASSEXTEND native) what should I see?
>>
>> I see FOO = "AB" which is not what I thought it would do...
>
>Hmm, this isn't what I'd expect either.  It's certainly not what was
>originally intended -- _append_<foo> and _prepend_<foo> were always
>supposed to act like normal _append/_prepend, just conditional ones.

I guess it's related to below lines (from finalize()):

                    # maybe the OVERRIDE was not yet added so keep the append
                    if (o and o in overrides) or not o:
                        self.delVarFlag(append, "_append")
                    if o and not o in overrides:
                        continue

FOO_append = "B" is parsed into ("B", NONE)
FOO_append_virtclass-native = "C" is parsed into ("C", virtclass-native)

If ("C", virtclass-native) is enumerated first, the result is desired: "C" is appended
to FOO with ("B", NONE) simply removed.

If ("B", NONE) is enumerated first, then the rest appendixes are removed too which
is not desired.

The net effect is that the 1st appendix always takes effect over the rest unless it
has an override which hasn't been found yet.

Besides this problem, there's also no consideration about override priority. It can't
handle multiple overrides on same FOO_append.

To solve it, we still need to iterate override list from highest priority to lowest end,
and then choose the value from the one firstly matching an override. My remote 
machine is down now and thus unable to verify it though.

Thanks
Kevin

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Sun, 2010-12-05 at 17:32 +0800, Tian, Kevin wrote:
> >From: Chris Larson
> >Sent: Monday, November 29, 2010 11:25 PM
> >On Mon, Nov 29, 2010 at 5:25 AM, Richard Purdie <rpurdie@linux.intel.com> wrote:
> >> Interestingly though, if I add this to curl*.bb:
> >>
> >> FOO = "A"
> >> FOO_append = "B"
> >> FOO_append_virtclass-native = "C"
> >>
> >> and then "bitbake curl-native -e | grep FOO" (he recipe has a
> >> BBCLASSEXTEND native) what should I see?
> >>
> >> I see FOO = "AB" which is not what I thought it would do...
> >
> >Hmm, this isn't what I'd expect either.  It's certainly not what was
> >originally intended -- _append_<foo> and _prepend_<foo> were always
> >supposed to act like normal _append/_prepend, just conditional ones.

This is what I'd have expected too.

> I guess it's related to below lines (from finalize()):
> 
>                     # maybe the OVERRIDE was not yet added so keep the append
>                     if (o and o in overrides) or not o:
>                         self.delVarFlag(append, "_append")
>                     if o and not o in overrides:
>                         continue

Correct, it is these lines that are the problem.

> FOO_append = "B" is parsed into ("B", NONE)
> FOO_append_virtclass-native = "C" is parsed into ("C", virtclass-native)
> 
> If ("C", virtclass-native) is enumerated first, the result is desired: "C" is appended
> to FOO with ("B", NONE) simply removed.
> 
> If ("B", NONE) is enumerated first, then the rest appendixes are removed too which
> is not desired.

This is exactly the problem.

> The net effect is that the 1st appendix always takes effect over the rest unless it
> has an override which hasn't been found yet.

Right. I had a play with the code and can confirm a patch as follows
fixes this problem. I've also made it warn when it finds code that would
effect behaviour. For Poky its throwing up a warning about EXTRA_OEMAKE
but its actually fine as whilst there is an unexpanded override, there
is never any _append or _prepend to trigger this bug (the warning can
show false positives). It would be nice to see if OE is suffering from
this problem anywhere before we accept this fix into bitbake upstream.
I'll also remove this error before this goes into Poky.

http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake&id=c77410305fe736aa195ce720c8317b39da057052

> Besides this problem, there's also no consideration about override priority. It can't
> handle multiple overrides on same FOO_append.
> 
> To solve it, we still need to iterate override list from highest priority to lowest end,
> and then choose the value from the one firstly matching an override. My remote 
> machine is down now and thus unable to verify it though.

This is a good point but its not a simple one :)

FOO = "A"
FOO_append_OVERA = "B"
FOO_append_OVERB = "C"

could result in ABC or ACB depending on whether OVERA was added to
OVERRIDES late on. There isn't much we can probably do about that
though.

FOO = "A"
FOO_append_OVERA_OVERB = "B"
FOO_append_OVERB_OVERA = "C"

plain won't work at present if I read the code correctly. I'm not sure
there is an ordering constraint here though as "ABC" is the correct
answer and either an OVERRIDE is appended or it isn't and priority isn't
an issue?

Chris: Any thoughts on any of this?

Cheers,

Richard

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: Richard Purdie [mailto:rpurdie@linux.intel.com]
>Sent: Monday, December 06, 2010 9:04 AM
>
>On Sun, 2010-12-05 at 17:32 +0800, Tian, Kevin wrote:
>> >From: Chris Larson
>> >Sent: Monday, November 29, 2010 11:25 PM
>> >On Mon, Nov 29, 2010 at 5:25 AM, Richard Purdie <rpurdie@linux.intel.com> wrote:
>> >> Interestingly though, if I add this to curl*.bb:
>> >>
>> >> FOO = "A"
>> >> FOO_append = "B"
>> >> FOO_append_virtclass-native = "C"
>> >>
>> >> and then "bitbake curl-native -e | grep FOO" (he recipe has a
>> >> BBCLASSEXTEND native) what should I see?
>> >>
>> >> I see FOO = "AB" which is not what I thought it would do...
>> >
>> >Hmm, this isn't what I'd expect either.  It's certainly not what was
>> >originally intended -- _append_<foo> and _prepend_<foo> were always
>> >supposed to act like normal _append/_prepend, just conditional ones.
>
>This is what I'd have expected too.
>
>> I guess it's related to below lines (from finalize()):
>>
>>                     # maybe the OVERRIDE was not yet added so keep the append
>>                     if (o and o in overrides) or not o:
>>                         self.delVarFlag(append, "_append")
>>                     if o and not o in overrides:
>>                         continue
>
>Correct, it is these lines that are the problem.
>
>> FOO_append = "B" is parsed into ("B", NONE)
>> FOO_append_virtclass-native = "C" is parsed into ("C", virtclass-native)
>>
>> If ("C", virtclass-native) is enumerated first, the result is desired: "C" is appended
>> to FOO with ("B", NONE) simply removed.
>>
>> If ("B", NONE) is enumerated first, then the rest appendixes are removed too which
>> is not desired.
>
>This is exactly the problem.
>
>> The net effect is that the 1st appendix always takes effect over the rest unless it
>> has an override which hasn't been found yet.
>
>Right. I had a play with the code and can confirm a patch as follows
>fixes this problem. I've also made it warn when it finds code that would
>effect behaviour. For Poky its throwing up a warning about EXTRA_OEMAKE
>but its actually fine as whilst there is an unexpanded override, there
>is never any _append or _prepend to trigger this bug (the warning can
>show false positives). It would be nice to see if OE is suffering from
>this problem anywhere before we accept this fix into bitbake upstream.
>I'll also remove this error before this goes into Poky.
>
>http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake&id=c77410305f
>e736aa195ce720c8317b39da057052

yes, that looks a clear fix.

>
>> Besides this problem, there's also no consideration about override priority. It can't
>> handle multiple overrides on same FOO_append.
>>
>> To solve it, we still need to iterate override list from highest priority to lowest end,
>> and then choose the value from the one firstly matching an override. My remote
>> machine is down now and thus unable to verify it though.
>
>This is a good point but its not a simple one :)
>
>FOO = "A"
>FOO_append_OVERA = "B"
>FOO_append_OVERB = "C"
>
>could result in ABC or ACB depending on whether OVERA was added to
>OVERRIDES late on. There isn't much we can probably do about that
>though.
>
>FOO = "A"
>FOO_append_OVERA_OVERB = "B"
>FOO_append_OVERB_OVERA = "C"
>
>plain won't work at present if I read the code correctly. I'm not sure
>there is an ordering constraint here though as "ABC" is the correct
>answer and either an OVERRIDE is appended or it isn't and priority isn't
>an issue?

Actually my original thought was a little bit different. Atm I thought that only one
appendix should take effect, i.e:

FOO = "A"
FOO_append_OVERA = "B"
FOO_append_OVERB = "C"

If OVERB is higher priority than OVERA, the result would be "AC" then.

Now obviously my earlier thought is wrong. Every _append appends a new
value if the override is valid. :-)

I also thought that there's no ordering constraint in this design. either "A B C"
or "A C B" could work, unless the appendix itself has order constraint, say 
a patch sequence. But I'm not sure whether there's real usage and we need
to handle it or not.

>
>Chris: Any thoughts on any of this?
>
>Cheers,
>
>Richard
>

Thanks
Kevin

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Tue, 2010-12-07 at 15:55 +0800, Tian, Kevin wrote:
> >From: Richard Purdie [mailto:rpurdie@linux.intel.com]
> >http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake&id=c77410305f
> >e736aa195ce720c8317b39da057052
> 
> yes, that looks a clear fix.

In the absence of Chris saying no, I've merged this into Poky so it
doesn't get lost.

> Actually my original thought was a little bit different. Atm I thought that only one
> appendix should take effect, i.e:
> 
> FOO = "A"
> FOO_append_OVERA = "B"
> FOO_append_OVERB = "C"
> 
> If OVERB is higher priority than OVERA, the result would be "AC" then.
> 
> Now obviously my earlier thought is wrong. Every _append appends a new
> value if the override is valid. :-)

Right, there is just the question of ordering.

> I also thought that there's no ordering constraint in this design. either "A B C"
> or "A C B" could work, unless the appendix itself has order constraint, say 
> a patch sequence. But I'm not sure whether there's real usage and we need
> to handle it or not.

I think its not something we should worry too much about, just something
to be aware of.

I do still think we should support FOO_append_OVERA_OVERB_OVERC though
perhaps we should leave a bug open on that?

Cheers,

Richard

Re: [PATCH 1/1] curl: fix native dependency

[Qing He]

On Tue, 2010-12-07 at 20:37 +0800, Richard Purdie wrote:
> On Tue, 2010-12-07 at 15:55 +0800, Tian, Kevin wrote:
> > >From: Richard Purdie [mailto:rpurdie@linux.intel.com]
> > >http://git.pokylinux.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bitbake&id=c77410305f
> > >e736aa195ce720c8317b39da057052
> > 
> > yes, that looks a clear fix.
> 
> In the absence of Chris saying no, I've merged this into Poky so it
> doesn't get lost.

Thank you for the fix, I've been looking the smart data section
recently, and the rationale becomes much clearer to me.


However, the following case still has some confusion:

FOO = "A"
FOO_append = "B"
FOO_virtclass-native = "C"

when in virtclass-native, the output is simply "C", instead of "CB"
as I expected

> 
> > Actually my original thought was a little bit different. Atm I thought that only one
> > appendix should take effect, i.e:
> > 
> > FOO = "A"
> > FOO_append_OVERA = "B"
> > FOO_append_OVERB = "C"
> > 
> > If OVERB is higher priority than OVERA, the result would be "AC" then.
> > 
> > Now obviously my earlier thought is wrong. Every _append appends a new
> > value if the override is valid. :-)
> 
> Right, there is just the question of ordering.
> 
> > I also thought that there's no ordering constraint in this design. either "A B C"
> > or "A C B" could work, unless the appendix itself has order constraint, say 
> > a patch sequence. But I'm not sure whether there's real usage and we need
> > to handle it or not.
> 
> I think its not something we should worry too much about, just something
> to be aware of.

There is some occasion where the ordering may matter, for example, CFLAGS
(and some other command line options). But even this may avoid the need of
predicatable order if we are careful.

> 
> I do still think we should support FOO_append_OVERA_OVERB_OVERC though
> perhaps we should leave a bug open on that?

This question also arose when I read the code, then I realize that
FOO_append_OVERA_OVERB_OVERC doesn't work in current design. Previously
I expected something like a staged handling, i.e. peeling off the
append/prepend first, and then handling override, but actually they are
not that loosely coupled.

That said, it seems supporting multiple overrides in append is still
ok, I tried to sketch a patch as follow, seems work for
FOO_append_virtclass-native_qemux86 = "C"

---
diff --git a/bitbake/lib/bb/data_smart.py b/bitbake/lib/bb/data_smart.py
index c8cd8f8..116ea10 100644
--- a/bitbake/lib/bb/data_smart.py
+++ b/bitbake/lib/bb/data_smart.py
@@ -160,9 +160,15 @@ class DataSmart:
                 for append in appends:
                     keep = []
                     for (a, o) in self.getVarFlag(append, op) or []:
-                        if o and not o in overrides:
-                            keep.append((a ,o))
-                            continue
+                        if o:
+                            applicable = 1
+                            for override in o.split('_'):
+                                if not override in overrides:
+                                    applicable = 0
+                                    break
+                            if not applicable:
+                                keep.append((a ,o))
+                                continue
 
                         if op is "_append":
                             sval = self.getVar(append, False) or ""
---


Thanks,
Qing

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Wed, 2010-12-08 at 11:12 +0800, Qing He wrote:
> Thank you for the fix, I've been looking the smart data section
> recently, and the rationale becomes much clearer to me.
> 
> However, the following case still has some confusion:
> 
> FOO = "A"
> FOO_append = "B"
> FOO_virtclass-native = "C"
> 
> when in virtclass-native, the output is simply "C", instead of "CB"
> as I expected

This is a tricky one. It would be interesting to see if this applies
with other overrides such as MACHINE. The reason I say that is the way
the virtclass-native override is added (see native.bbclass).

> > > I also thought that there's no ordering constraint in this design. either "A B C"
> > > or "A C B" could work, unless the appendix itself has order constraint, say 
> > > a patch sequence. But I'm not sure whether there's real usage and we need
> > > to handle it or not.
> > 
> > I think its not something we should worry too much about, just something
> > to be aware of.
> 
> There is some occasion where the ordering may matter, for example, CFLAGS
> (and some other command line options). But even this may avoid the need of
> predicatable order if we are careful.

Right, there are cases it will matter like patch application but we just
need to be sensitive to that when writing metadata.

> > I do still think we should support FOO_append_OVERA_OVERB_OVERC though
> > perhaps we should leave a bug open on that?
> 
> This question also arose when I read the code, then I realize that
> FOO_append_OVERA_OVERB_OVERC doesn't work in current design. Previously
> I expected something like a staged handling, i.e. peeling off the
> append/prepend first, and then handling override, but actually they are
> not that loosely coupled.

I'd also actually thought the code worked differently to how it does
before I looked at it!

> That said, it seems supporting multiple overrides in append is still
> ok, I tried to sketch a patch as follow, seems work for
> FOO_append_virtclass-native_qemux86 = "C"

This looks reasonable. In python you should used "True" and "False"
instead of "1" and "0".

I've just mentally been asking myself what if this was a variable like
SRC_URI where the name contains an "_" but since we don't allow
overrides to contain the character, I think we're safe.

I also think you can simplify the logic slightly to be:

+                            for override in o.split('_'):
+                                if not override in overrides:
+                                    keep.append((a ,o)) 
+                                    continue

?

Cheers,

Richard

> ---
> diff --git a/bitbake/lib/bb/data_smart.py b/bitbake/lib/bb/data_smart.py
> index c8cd8f8..116ea10 100644
> --- a/bitbake/lib/bb/data_smart.py
> +++ b/bitbake/lib/bb/data_smart.py
> @@ -160,9 +160,15 @@ class DataSmart:
>                  for append in appends:
>                      keep = []
>                      for (a, o) in self.getVarFlag(append, op) or []:
> -                        if o and not o in overrides:
> -                            keep.append((a ,o))
> -                            continue
> +                        if o:
> +                            applicable = 1
> +                            for override in o.split('_'):
> +                                if not override in overrides:
> +                                    applicable = 0
> +                                    break
> +                            if not applicable:
> +                                keep.append((a ,o))
> +                                continue
>  
>                          if op is "_append":
>                              sval = self.getVar(append, False) or ""
> ---
> 
> 
> Thanks,
> Qing
> 

Re: [PATCH 1/1] curl: fix native dependency

[Qing He]

On Thu, 2010-12-09 at 23:16 +0800, Richard Purdie wrote:
> On Wed, 2010-12-08 at 11:12 +0800, Qing He wrote:
> > Thank you for the fix, I've been looking the smart data section
> > recently, and the rationale becomes much clearer to me.
> > 
> > However, the following case still has some confusion:
> > 
> > FOO = "A"
> > FOO_append = "B"
> > FOO_virtclass-native = "C"
> > 
> > when in virtclass-native, the output is simply "C", instead of "CB"
> > as I expected
> 
> This is a tricky one. It would be interesting to see if this applies
> with other overrides such as MACHINE. The reason I say that is the way
> the virtclass-native override is added (see native.bbclass).

So you mean this is intended? The FOO_append is meant to be hidden by
the use of an override? I'd rather have expected something like this:

---
diff --git a/bitbake/lib/bb/data_smart.py b/bitbake/lib/bb/data_smart.py
index c8cd8f8..3e4c710 100644
--- a/bitbake/lib/bb/data_smart.py
+++ b/bitbake/lib/bb/data_smart.py
@@ -149,6 +149,11 @@ class DataSmart:
             for var in vars:
                 name = var[:-l]
                 try:
+                    for op in __setvar_keyword__:
+                        if op in self[name]:
+                            sval = self.getVarFlag(name, op, False)
+                            self.setVarFlag(var, op, sval)
+
                     self[name] = self[var]
                 except Exception:
                     bb.msg.note(1, bb.msg.domain.Data, "Untracked delVar")

---


> SRC_URI where the name contains an "_" but since we don't allow
> overrides to contain the character, I think we're safe.
> 
> I also think you can simplify the logic slightly to be:
> 
> +                            for override in o.split('_'):
> +                                if not override in overrides:
> +                                    keep.append((a ,o)) 
> +                                    continue
> 
> ?
> 

This `continue' falls into the scope of `for override in o.split'
instead of the former one, chances are the (a, o) can be appended
more than once if multiple overrides not present.

Thanks,
Qing

Re: [PATCH 1/1] curl: fix native dependency

[Qing He]

On Mon, 2010-12-13 at 13:52 +0800, Qing He wrote:
> On Thu, 2010-12-09 at 23:16 +0800, Richard Purdie wrote:
> > On Wed, 2010-12-08 at 11:12 +0800, Qing He wrote:
> > > Thank you for the fix, I've been looking the smart data section
> > > recently, and the rationale becomes much clearer to me.
> > > 
> > > However, the following case still has some confusion:
> > > 
> > > FOO = "A"
> > > FOO_append = "B"
> > > FOO_virtclass-native = "C"
> > > 
> > > when in virtclass-native, the output is simply "C", instead of "CB"
> > > as I expected
> > 
> > This is a tricky one. It would be interesting to see if this applies
> > with other overrides such as MACHINE. The reason I say that is the way
> > the virtclass-native override is added (see native.bbclass).
> 
> So you mean this is intended? The FOO_append is meant to be hidden by
> the use of an override? I'd rather have expected something like this:
> 
> ---
> diff --git a/bitbake/lib/bb/data_smart.py b/bitbake/lib/bb/data_smart.py
> index c8cd8f8..3e4c710 100644
> --- a/bitbake/lib/bb/data_smart.py
> +++ b/bitbake/lib/bb/data_smart.py
> @@ -149,6 +149,11 @@ class DataSmart:
>              for var in vars:
>                  name = var[:-l]
>                  try:
> +                    for op in __setvar_keyword__:
> +                        if op in self[name]:
> +                            sval = self.getVarFlag(name, op, False)
> +                            self.setVarFlag(var, op, sval)
> +
>                      self[name] = self[var]
>                  except Exception:
>                      bb.msg.note(1, bb.msg.domain.Data, "Untracked delVar")
> 
> ---

never mind, I thought "self[name]" as "self.dict[name]", it turns out to
be __setitem__ which is at last a setVar() call.

Thanks,
Qing

Re: [PATCH 1/1] curl: fix native dependency

[Qing He]

On Mon, 2010-11-29 at 20:25 +0800, Richard Purdie wrote:
> On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
> > On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
> > > This also confuses me a bit. When virtclass-native is expanded, EXTRA_OECONF_append
> > > is simply a variable. In that case the expanded value should override the 1st assignment
> > > of EXTRA_OECONF_append, and then we should get:
> > >
> > > EXTRA_OECONF_append = " --without-gnutls "
> > >
> > > and then that's what we expect.
> > >
> > > I guess I may still overlook something here, and really appreciate your explanation
> > > on the whole flow which is helpful. :-)
> > 
> > No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
> > operations, not part of the name.  The value gets set aside in a list
> > of appends for that variable.  One _append cannot override/replace
> > another on the same variable, its always cumulative.
> 
> Right.
> 
> Interestingly though, if I add this to curl*.bb:
> 
> FOO = "A"
> FOO_append = "B"
> FOO_append_virtclass-native = "C"
> 
> and then "bitbake curl-native -e | grep FOO" (he recipe has a
> BBCLASSEXTEND native) what should I see?
> 
> I see FOO = "AB" which is not what I thought it would do...

This is very interesting, I didn't see "AC" when preparing the patch
so went the other way. After seeing your experiment, I also tried this:

FOO = "A"
FOO_virtclass-native = "B"
FOO_virtclass-native_append = "C"

Then for curl-native, FOO = "BC", and there is an explicit variable
FOO_virtclass-native = "BC", this does not exist in RP's test.
So it's more clear to me now what "*_append is never a variable" means.


However, the gut feeling is that this construct introduces some
inconsistency. If "_append" is never a variable, but "_virtclass-native"
is, how is bitbake supposed to handle FOO_append_virtclass-native and
translate it into a FOO_virtclass-native variable?

To be more specific, if append is to be handled earlier than virtclass,
FOO may not be able to be evaluated at the time when append/prepend is
processed, as the following test case:

FOO = "A"
FOO_virtclass-native = "B"
FOO_append = "C"
FOO_append_virtclass-nativesdk = "D"

How should it be handled?

Thanks,
Qing

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: He, Qing
>Sent: Tuesday, November 30, 2010 9:44 AM
>
>On Mon, 2010-11-29 at 20:25 +0800, Richard Purdie wrote:
>> On Sun, 2010-11-28 at 22:53 -0700, Chris Larson wrote:
>> > On Sun, Nov 28, 2010 at 10:26 PM, Tian, Kevin <kevin.tian@intel.com> wrote:
>> > > This also confuses me a bit. When virtclass-native is expanded,
>EXTRA_OECONF_append
>> > > is simply a variable. In that case the expanded value should override the 1st
>assignment
>> > > of EXTRA_OECONF_append, and then we should get:
>> > >
>> > > EXTRA_OECONF_append = " --without-gnutls "
>> > >
>> > > and then that's what we expect.
>> > >
>> > > I guess I may still overlook something here, and really appreciate your explanation
>> > > on the whole flow which is helpful. :-)
>> >
>> > No, EXTRA_OECONF_append is never a variable.  _append/_prepend are
>> > operations, not part of the name.  The value gets set aside in a list
>> > of appends for that variable.  One _append cannot override/replace
>> > another on the same variable, its always cumulative.
>>
>> Right.
>>
>> Interestingly though, if I add this to curl*.bb:
>>
>> FOO = "A"
>> FOO_append = "B"
>> FOO_append_virtclass-native = "C"
>>
>> and then "bitbake curl-native -e | grep FOO" (he recipe has a
>> BBCLASSEXTEND native) what should I see?
>>
>> I see FOO = "AB" which is not what I thought it would do...
>
>This is very interesting, I didn't see "AC" when preparing the patch
>so went the other way. After seeing your experiment, I also tried this:
>
>FOO = "A"
>FOO_virtclass-native = "B"
>FOO_virtclass-native_append = "C"
>
>Then for curl-native, FOO = "BC", and there is an explicit variable
>FOO_virtclass-native = "BC", this does not exist in RP's test.
>So it's more clear to me now what "*_append is never a variable" means.
>
>
>However, the gut feeling is that this construct introduces some
>inconsistency. If "_append" is never a variable, but "_virtclass-native"
>is, how is bitbake supposed to handle FOO_append_virtclass-native and
>translate it into a FOO_virtclass-native variable?

See finalize() in data_smart.py. the override for _append/_prepend is handled
specifically which is different from normal overrides tweak. There's some bug
though which I described in another mail. In a nutshell, FOO_append_virtclass-native
is parsed into a flag for FOO, with name as 'append', the value as ("C", virtclass-native).
when finalize() handles _append/_prepend, "C" is appended to FOO directly and
thus there's no FOO_virtclass-native being generated in the middle.

I'm not sure whether FOO_virtclass-native_append = "C" is a valid usage though.
At least it's not in current design. As in your example, finally a new variable
is created (FOO_virtclass-native) with value as 'BC'. Though override is handled
before _append/_prepend, finalize() may be invoked multiple times. The 1st time
will give you:

FOO = "A"
FOO_virtclass-native = "BC"

and then later invocations will get:

FOO = "BC"
FOO_virtclass-native = "BC"

This though gives a right result in the end, it's dangerous as its value is volatile
in the middle.

>
>To be more specific, if append is to be handled earlier than virtclass,
>FOO may not be able to be evaluated at the time when append/prepend is
>processed, as the following test case:
>
>FOO = "A"
>FOO_virtclass-native = "B"
>FOO_append = "C"
>FOO_append_virtclass-nativesdk = "D"
>
>How should it be handled?
>

The expected result will be:

a) if you build pkgname, you'll get FOO = "AC" as the effect of _append

b) if you build pkgname-native, you'll get FOO = "BC" because overrides are
handled before _append/_prepend

a) if you build pkgname-nativesdk, you'll get FOO = "AD" because override
appendix is used

Thanks
Kevin

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Sun, 2010-12-05 at 17:43 +0800, Tian, Kevin wrote:
> >From: He, Qing
> >Sent: Tuesday, November 30, 2010 9:44 AM
> >To be more specific, if append is to be handled earlier than virtclass,
> >FOO may not be able to be evaluated at the time when append/prepend is
> >processed, as the following test case:
> >
> >FOO = "A"
> >FOO_virtclass-native = "B"
> >FOO_append = "C"
> >FOO_append_virtclass-nativesdk = "D"
> >
> >How should it be handled?
> >
> 
> The expected result will be:
> 
> a) if you build pkgname, you'll get FOO = "AC" as the effect of _append
> 
> b) if you build pkgname-native, you'll get FOO = "BC" because overrides are
> handled before _append/_prepend
> 
> a) if you build pkgname-nativesdk, you'll get FOO = "AD" because override
> appendix is used

but this last case should be ACD as I think we've determined there is a
bug in bitbake :)

Cheers,

Richard

Re: [PATCH 1/1] curl: fix native dependency

[Tian, Kevin]

>From: Richard Purdie [mailto:rpurdie@linux.intel.com]
>Sent: Monday, December 06, 2010 9:10 AM
>
>On Sun, 2010-12-05 at 17:43 +0800, Tian, Kevin wrote:
>> >From: He, Qing
>> >Sent: Tuesday, November 30, 2010 9:44 AM
>> >To be more specific, if append is to be handled earlier than virtclass,
>> >FOO may not be able to be evaluated at the time when append/prepend is
>> >processed, as the following test case:
>> >
>> >FOO = "A"
>> >FOO_virtclass-native = "B"
>> >FOO_append = "C"
>> >FOO_append_virtclass-nativesdk = "D"
>> >
>> >How should it be handled?
>> >
>>
>> The expected result will be:
>>
>> a) if you build pkgname, you'll get FOO = "AC" as the effect of _append
>>
>> b) if you build pkgname-native, you'll get FOO = "BC" because overrides are
>> handled before _append/_prepend
>>
>> a) if you build pkgname-nativesdk, you'll get FOO = "AD" because override
>> appendix is used
>
>but this last case should be ACD as I think we've determined there is a
>bug in bitbake :)
>

yes, you are correct. :-)

Thanks
Kevin

Re: [PATCH 1/1] curl: fix native dependency

[Qing He]

On Sun, 2010-11-28 at 22:22 +0800, Richard Purdie wrote:
> On Wed, 2010-11-17 at 16:26 +0800, Qing He wrote:
> > @@ -25,6 +24,10 @@ EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
> >  		--enable-crypto-auth \
> >  		"
> >  
> > +EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
> > +EXTRA_OECONF_virtclass-native_append = " --without-gnutls"
> > +EXTRA_OECONF_virtclass-nativesdk_append = " --without-gnutls"
> > +
> >  do_configure_prepend() {
> >  	sed -i s:OPT_GNUTLS/bin:OPT_GNUTLS:g configure.ac
> >  }
> 
> I'm going to push a fix but I wanted to note that the above is not
> correct. Let me walk through this since I expect various people find
> this confusing.

Thanks for the explanation.

In fact, at first, I also tried to use
EXTRA_OECONF_append_virtclass-native, in the hope to override variable
EXTRA_OECONF_append for different virtual classes. However, the
log.do_configure still showed "--with-gnutls=...", that's why I then
changed to the form in the patch, and it looked working.


And I also see something in the smart data implementation:
    __setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend)(_(?P<add>.*))?')

Does that mean append/prepend is expected to appear before everything
else?

Thanks,
Qing

Re: [PATCH 1/1] curl: fix native dependency

[Richard Purdie]

On Mon, 2010-11-29 at 16:17 +0800, Qing He wrote:
> On Sun, 2010-11-28 at 22:22 +0800, Richard Purdie wrote:
> > On Wed, 2010-11-17 at 16:26 +0800, Qing He wrote:
> > > @@ -25,6 +24,10 @@ EXTRA_OECONF = "--with-zlib=${STAGING_LIBDIR}/../ \
> > >  		--enable-crypto-auth \
> > >  		"
> > >  
> > > +EXTRA_OECONF_append = " --with-gnutls=${STAGING_LIBDIR}/../"
> > > +EXTRA_OECONF_virtclass-native_append = " --without-gnutls"
> > > +EXTRA_OECONF_virtclass-nativesdk_append = " --without-gnutls"
> > > +
> > >  do_configure_prepend() {
> > >  	sed -i s:OPT_GNUTLS/bin:OPT_GNUTLS:g configure.ac
> > >  }
> > 
> > I'm going to push a fix but I wanted to note that the above is not
> > correct. Let me walk through this since I expect various people find
> > this confusing.
> 
> Thanks for the explanation.
> 
> In fact, at first, I also tried to use
> EXTRA_OECONF_append_virtclass-native, in the hope to override variable
> EXTRA_OECONF_append for different virtual classes. However, the
> log.do_configure still showed "--with-gnutls=...", that's why I then
> changed to the form in the patch, and it looked working.
> 
> 
> And I also see something in the smart data implementation:
>     __setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend)(_(?P<add>.*))?')
> 
> Does that mean append/prepend is expected to appear before everything
> else?

It means append and prepend only work if they're the last part of the
variable name.

e.g. XXX_append = "YYY"

so XXX_append_ZZZ = "YYY" won't do anything

of course if ZZZ is an override, it will be peeled off but the append
only happens after its been overridden and it becomes XXX_append

Cheers,

Richard

Re: [PATCH 0/1] curl-native build fix

[Saul Wold]

On 11/17/2010 12:32 AM, Qing He wrote:
>
> Pull URL: git://git.pokylinux.org/poky-contrib.git
>    Branch: qhe/fix
>    Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=qhe/fix
>
> Thanks,
>      Qing He
> ---
>
>
> Qing He (1):
>    curl: fix native dependency
Can you give more details about why this change was needed at this point?

Thanks
    Sau!

>
>   meta/recipes-support/curl/curl_7.21.2.bb |    7 +++++--
>   1 files changed, 5 insertions(+), 2 deletions(-)
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>

Re: [PATCH 0/1] curl-native build fix

[Scott Garman]

On 11/17/2010 10:21 AM, Saul Wold wrote:
> On 11/17/2010 12:32 AM, Qing He wrote:
>>
>> Pull URL: git://git.pokylinux.org/poky-contrib.git
>>     Branch: qhe/fix
>>     Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=qhe/fix
>>
>> Thanks,
>>       Qing He
>> ---
>>
>>
>> Qing He (1):
>>     curl: fix native dependency
> Can you give more details about why this change was needed at this point?

Saul,

This was a problem I had reported to Qing off-list. It causes 
curl-native to fail on my Ubuntu 10.10 hosts.

Scott

-- 
Scott Garman
Embedded Linux Distro Engineer - Yocto Project

Re: [PATCH 0/1] curl-native build fix

[Saul Wold]

On 11/17/2010 10:26 AM, Scott Garman wrote:
> On 11/17/2010 10:21 AM, Saul Wold wrote:
>> On 11/17/2010 12:32 AM, Qing He wrote:
>>>
>>> Pull URL: git://git.pokylinux.org/poky-contrib.git
>>>      Branch: qhe/fix
>>>      Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=qhe/fix
>>>
>>> Thanks,
>>>        Qing He
>>> ---
>>>
>>>
>>> Qing He (1):
>>>      curl: fix native dependency
>> Can you give more details about why this change was needed at this point?
>
> Saul,
>
> This was a problem I had reported to Qing off-list. It causes
> curl-native to fail on my Ubuntu 10.10 hosts.
>
Scott,

So we root-caused this to be because you had the gnutls-dev package 
installed on your system, so I am still not conviced that disabling 
gnutls on the native side is correct.  We might need to look at adding 
gnutls as a native dependency of curl-native.

I will investigate this further.

Sau!

> Scott
>