[OE-core] [PATCH 36/52] gettext.bbclass: Use _append instead of =+

Khem Raj raj.khem at gmail.com
Thu May 5 16:58:39 UTC 2011


On Thu, May 5, 2011 at 2:41 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2011-05-04 at 18:07 -0700, Khem Raj wrote:
>> a build from scratch revealed few more issues with this patch too.
>>
>> 1. We have to only remove gettext from dependencies if its a target
>> package for all other it still it needed otherwise all native and
>> cross tools start failing to build
>>  e.g. binutils-cross this can be easily solved by a patch
>>
>> iff --git a/meta/classes/gettext.bbclass b/meta/classes/gettext.bbclass
>> index 6f79e5e..cc39204 100644
>> --- a/meta/classes/gettext.bbclass
>> +++ b/meta/classes/gettext.bbclass
>> @@ -1,5 +1,5 @@
>>  def gettext_dependencies(d):
>> -    if d.getVar('USE_NLS', True) == 'no':
>> +    if d.getVar('USE_NLS', True) == 'no' and not oe.utils.inherits(d,
>> 'native', 'nativesdk', 'cross')
>>          return ""
>>      if bb.data.getVar('INHIBIT_DEFAULT_DEPS', d, True) and not
>> oe.utils.inherits(d, 'cross-canadian')
>>          return ""
>
> This looks reasonable, its still much clearer what is happening and why
> compared to the original version...
>
>> second problem is that EXTRA_OECONF when recipes override it instead
>> of += or appending etc.
>> then --enable|--disable-nls that we added via gettext_oeconf() is lost
>> as a result some packages complain about config.rpath
>> when USE_NLS is set to no the reason is their configure is missing the
>> argument --disable-nls this works ok
>> for eglibc based targets since default is to enable-nls if nothing is
>> specified but uclibc fails. As a testcase try to preprocess
>> utils-linux
>> recipe and check the contents of EXTRA_OECONF
>
> I suspect we can fix this with:
>
> -EXTRA_OECONF += "${@gettext_oeconf(d)}"
> +EXTRA_OECONF_append = " ${@gettext_oeconf(d)}"
>
> ?
>
yes something like that
somehow the patch I attached did not make it to ml
I have sent it separately now.


> Cheers,
>
> Richard
>
>




More information about the Openembedded-core mailing list