Re: [CONSOLIDATED PULL 4/4] multiple recipes converted to -staticdev packages

[Saul Wold <sgw@linux.intel.com>]

On 06/10/2011 02:36 PM, Phil Blundell wrote:
> On Fri, 2011-06-10 at 11:36 -0700, Saul Wold wrote:
>>>> +FILES_eglibc-dev_append += "${bindir}/rpcgen ${base_libdir}/*.o ${datadir}/aclocal"
>>>> +FILES_eglibc-staticdev_append += "${libdir}/*.a ${base_libdir}/*.a"
>>>
>>> You need to make sure that libc_nonshared.a goes into -dev rather than
>>> -staticdev somehow.  I didn't immediately spot any mechanism which would
>>> do this, though I haven't tested the package to find out what happens.
>>>
>>>> +FILES_uclibc-staticdev_append = "\
>>>> +        ${libdir}/*_nonshared.a \
>>>> +        ${libdir}/lib*.a \
>>>
>>> In similar vein, this doesn't look right.
>>>
>> I think I should be able to remove nonshared from a list.
>
> I'm not entirely sure I understand what you said there.  Just to be
> totally clear, for eglibc and glibc at least (and I imagine uclibc too),
> libc_nonshared.a needs to go into the -dev package and not -staticdev.
> So I don't think it should ever be appearing in a FILES...staticdev
> list.
>
I understand that, Khem also mentioned it.  It a matter of doing some 
python RE stuff to drop them from the -staticdev list.

>>> This one is a bit odd: it seems to just be dropping the .a files
>>> altogether without introducing a -staticdev package for them.
>>>
>> I thought that maybe the default rule provided in bitbake.conf should
>> accomplish this since it is FILES_${PN}-staticdev = "${libdir}/*.a
>> ${base_libdir}/*.a"
>
> Ah yes, right.
>
>>>> +#FILES_${PN}-dev = " ${includedir}/a52dec/*.h ${libdir}/liba52.so ${libdir}/liba52.la "
>>>> +#FILES_${PN}-staticdev = " ${libdir}/liba52.a "
>>>
>>> This is a bit weird.  What's going on here?
>>>
>> As above, trying to ensure that the default bitbake.conf rules would work.
>
> Okay, fair enough.  But in that case please don't leave the old bits
> commented out.
>
Right, that was a goof on my part.

>>> All in all I think this patch needs a bit more work.  It was quite a big
>>> diff so I only skimmed it rather than reviewing it thoroughly but I
>>> don't think it is quite ready to go in yet.  Also, can't a lot of this
>>> be done in bitbake.conf without quite so much recipe patching?
>>>
>> Most of it is done there, I was looking at adding a staticdev.bbclass
>> that would handle the lib${PN} case generically, as a second phase of this.
>
> Can the RDEPENDS_${PN}-staticdev not go in bitbake.conf?  That would
> avoid all these cut and paste errors that seem to be plaguing that
> particular area.
>
Arealy in bitbake.conf, it's the RDEPENDS_lib${PN}-staticdev (note the 
'lib' prefix), this is special for a hand full, if I can set up the 
inherit than it done that way.


> p.
>
>
>