[v2,09/10] binutils.inc: add vardep on multiarch DISTRO_FEATURE

Submitted by Matthew McClintock on Sept. 28, 2012, 1:33 a.m.

Details

Message ID 1348795994-21695-9-git-send-email-msm@freescale.com
State New
Headers show

Commit Message

Matthew McClintock Sept. 28, 2012, 1:33 a.m.
binutils will build differently if this feature is enabled, so
make the do_configure step depend on it

Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Not sure if we should try to fix via configure options

v2: update commit message a bit

 meta/recipes-devtools/binutils/binutils.inc |    2 ++
 1 file changed, 2 insertions(+)

Patch hide | download patch | download mbox

diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
index ee748a4..ff64882 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -80,6 +80,8 @@  export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
 export CPP_FOR_BUILD = "${BUILD_CPP}"
 export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
 
+MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", "no", d)}"
+do_configure[vardeps] += "MULTIARCH"
 do_configure () {
 	(cd ${S}; gnu-configize) || die "Failed to run gnu-configize"
 	oe_runconf

Comments

Richard Purdie Sept. 28, 2012, 10:32 a.m.
On Thu, 2012-09-27 at 20:33 -0500, Matthew McClintock wrote:
> binutils will build differently if this feature is enabled, so
> make the do_configure step depend on it
> 
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> Not sure if we should try to fix via configure options
> 
> v2: update commit message a bit
> 
>  meta/recipes-devtools/binutils/binutils.inc |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
> index ee748a4..ff64882 100644
> --- a/meta/recipes-devtools/binutils/binutils.inc
> +++ b/meta/recipes-devtools/binutils/binutils.inc
> @@ -80,6 +80,8 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
>  export CPP_FOR_BUILD = "${BUILD_CPP}"
>  export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
>  
> +MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", "no", d)}"
> +do_configure[vardeps] += "MULTIARCH"
>  do_configure () {
>  	(cd ${S}; gnu-configize) || die "Failed to run gnu-configize"
>  	oe_runconf

This doesn't make sense. oe_runconf should depend on EXTRA_OECONF and
that should depend on DISTRO_FEATURES so the dependency should already
exist?

Cheers,

Richard
McClintock Matthew-B29882 Sept. 28, 2012, 3:07 p.m.
On Fri, Sep 28, 2012 at 5:32 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2012-09-27 at 20:33 -0500, Matthew McClintock wrote:
>> binutils will build differently if this feature is enabled, so
>> make the do_configure step depend on it
>>
>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>> ---
>> Not sure if we should try to fix via configure options
>>
>> v2: update commit message a bit
>>
>>  meta/recipes-devtools/binutils/binutils.inc |    2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
>> index ee748a4..ff64882 100644
>> --- a/meta/recipes-devtools/binutils/binutils.inc
>> +++ b/meta/recipes-devtools/binutils/binutils.inc
>> @@ -80,6 +80,8 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
>>  export CPP_FOR_BUILD = "${BUILD_CPP}"
>>  export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
>>
>> +MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", "no", d)}"
>> +do_configure[vardeps] += "MULTIARCH"
>>  do_configure () {
>>       (cd ${S}; gnu-configize) || die "Failed to run gnu-configize"
>>       oe_runconf
>
> This doesn't make sense. oe_runconf should depend on EXTRA_OECONF and
> that should depend on DISTRO_FEATURES so the dependency should already
> exist?

OK, maybe... let me just explain what I did to see an issue.

Let's say I did a build without MULTIARCH and everything went fine.
Then I went back and added mutliarch. binutils would not rebuild with
the new features and things would break. With this patch, after added
multiarch binutils would rebuild and the the build work OK.

As you say though, if this was an actual dep it should have rebuilt
already? Has anything changed in this area very recently?

-M
McClintock Matthew-B29882 Sept. 28, 2012, 4:15 p.m.
On Fri, Sep 28, 2012 at 10:06 AM, Matthew McClintock <msm@freescale.com> wrote:
> On Fri, Sep 28, 2012 at 5:32 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Thu, 2012-09-27 at 20:33 -0500, Matthew McClintock wrote:
>>> binutils will build differently if this feature is enabled, so
>>> make the do_configure step depend on it
>>>
>>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>>> ---
>>> Not sure if we should try to fix via configure options
>>>
>>> v2: update commit message a bit
>>>
>>>  meta/recipes-devtools/binutils/binutils.inc |    2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/recipes-devtools/binutils/binutils.inc b/meta/recipes-devtools/binutils/binutils.inc
>>> index ee748a4..ff64882 100644
>>> --- a/meta/recipes-devtools/binutils/binutils.inc
>>> +++ b/meta/recipes-devtools/binutils/binutils.inc
>>> @@ -80,6 +80,8 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
>>>  export CPP_FOR_BUILD = "${BUILD_CPP}"
>>>  export CFLAGS_FOR_BUILD = "${BUILD_CFLAGS}"
>>>
>>> +MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", "no", d)}"
>>> +do_configure[vardeps] += "MULTIARCH"
>>>  do_configure () {
>>>       (cd ${S}; gnu-configize) || die "Failed to run gnu-configize"
>>>       oe_runconf
>>
>> This doesn't make sense. oe_runconf should depend on EXTRA_OECONF and
>> that should depend on DISTRO_FEATURES so the dependency should already
>> exist?
>
> OK, maybe... let me just explain what I did to see an issue.
>
> Let's say I did a build without MULTIARCH and everything went fine.
> Then I went back and added mutliarch. binutils would not rebuild with
> the new features and things would break. With this patch, after added
> multiarch binutils would rebuild and the the build work OK.
>
> As you say though, if this was an actual dep it should have rebuilt
> already? Has anything changed in this area very recently?

Looking closer it seems like EXTRA_OECONF does not do this quite right
when resolving base_contains parameters:

List of dependencies for variable EXTRA_OECONF is
set(['gettext_oeconf', 'STAGING_DIR_TARGET', 'base_contains',
'TARGET_PREFIX'])

-M