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.




_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to