Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Kang Kai <Kai.Kang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Zhenfeng.Zhao@windriver.com, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/2] nativesdk-autoconf: add dependencies
Date: Mon, 22 Oct 2012 18:15:32 +0800	[thread overview]
Message-ID: <50851CC4.6040501@windriver.com> (raw)
In-Reply-To: <1350658913.2520.34.camel@ted>

On 2012年10月19日 23:01, Richard Purdie wrote:
> On Fri, 2012-10-19 at 19:22 +0800, Kang Kai wrote:
>> When use toolchain gmae to compile iptables, autoreconf needs perl and
>> some perl modules. It is too many item to put in the .bb file, so just
>> add nativesdk-perl-modules to provide them.
>>
>> [Yocto 3100]
>>
>> Signed-off-by: Kang Kai<kai.kang@windriver.com>
>> ---
>>   meta/recipes-devtools/autoconf/autoconf.inc     |    4 +++-
>>   meta/recipes-devtools/autoconf/autoconf_2.69.bb |    2 +-
>>   2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/autoconf/autoconf.inc b/meta/recipes-devtools/autoconf/autoconf.inc
>> index 315e773..29d67a0 100644
>> --- a/meta/recipes-devtools/autoconf/autoconf.inc
>> +++ b/meta/recipes-devtools/autoconf/autoconf.inc
>> @@ -10,7 +10,9 @@ DEPENDS_virtclass-native = "m4-native gnu-config-native"
>>   DEPENDS_virtclass-nativesdk = "nativesdk-m4 nativesdk-gnu-config"
>>   RDEPENDS_${PN} = "m4 gnu-config"
>>   RDEPENDS_${PN}_virtclass-native = "m4-native gnu-config-native"
>> -RDEPENDS_${PN}_virtclass-nativesdk = "nativesdk-m4 nativesdk-gnu-config"
>> +RDEPENDS_${PN}_virtclass-nativesdk = "nativesdk-m4 nativesdk-gnu-config \
>> +                                      nativesdk-perl nativesdk-perl-modules \
>> +                                     "
>>
> Ok, this is getting closer but I'm still not 100% convinced we have
> everything fixed properly. For example, if the above is true, isn't
> RDEPENDS_${PN} wrong? Do we need everything in perl-modules?
>
> I also took a look at the automake recipe which in some ways looks
> better behaved. It does:
>
> RDEPENDS_${PN} += "\
>      autoconf \
>      perl \
>      perl-module-bytes \
>      perl-module-constant \
>      perl-module-cwd \
>      perl-module-data-dumper \
>      perl-module-dynaloader \
>      perl-module-errno \
>      perl-module-exporter-heavy \
>      perl-module-file-basename \
>      perl-module-file-compare \
>      perl-module-file-copy \
>      perl-module-file-glob \
>      perl-module-file-spec-unix \
>      perl-module-file-stat \
>      perl-module-getopt-long \
>      perl-module-io \
>      perl-module-io-file \
>      perl-module-posix \
>      perl-module-strict \
>      perl-module-text-parsewords \
>      perl-module-vars "
>
> RDEPENDS_${PN}_virtclass-native = "autoconf-native perl-native-runtime"
> RDEPENDS_${PN}_virtclass-nativesdk = "nativesdk-autoconf"
>
> which at least seems to list the modules it really needs. The fact we
> then set a virtclass-nativesdk version which is wrong is worrying.
>
> I think the assumption has been that for nativesdk, we'd use the system
> perl.
>
> So I think we need to

Hi Richard,

> a) Decide whether the sdk should be using the nativesdk perl or the host
> system one. I'm fine with deciding we should use the nativesdk perl
> b) Fix RDEPENDS_${PN} for autoconf so that it lists the right perl
> modules.

I have put every single perl module to autoconf's rdepend. I also update 
the dependencies among perl modules themselves.

> c) At this pooint we might be able to simply remove RDEPENDS_
> ${PN}_virtclass-nativesdk and the code should figure things out
> automagically itself.

It looks fine when remove the RDEPENDS_ ${PN}_virtclass-nativesdk from 
autoconf.

> d) We should verify the list of modules for automake is correct

Because automake depends on autoconf, so how about I remove the 
perl-module-* in automake's rdepends these already in autoconf rdepends?
> e) We should also see if we can simply remove the RDEPENDS_
> ${PN}_virtclass-nativesdk line from automake.

I'll try to remove it.

Thanks,
Kai


>
> Does that make sense?
>
> Cheers,
>
> Richard
>
>
>
>
>
>
>
>
>
>




  reply	other threads:[~2012-10-22 10:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19 11:22 [PATCH 0/2] Fix (nativesdk-)perl dependency issues Kang Kai
2012-10-19 11:22 ` [PATCH 1/2] perl: fix dependecies Kang Kai
2012-10-19 11:22 ` [PATCH 2/2] nativesdk-autoconf: add dependencies Kang Kai
2012-10-19 15:01   ` Richard Purdie
2012-10-22 10:15     ` Kang Kai [this message]
2012-10-22 10:47       ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50851CC4.6040501@windriver.com \
    --to=kai.kang@windriver.com \
    --cc=Zhenfeng.Zhao@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox