All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.