Patchwork [03/26] shared_lib.bbclass: create common class

login
register
mail settings
Submitter Saul Wold
Date July 11, 2011, 11:13 p.m.
Message ID <1122cff5b635c23b36bc76ad58a088f522ac21a5.1310425837.git.sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/7357/
State New, archived
Headers show

Comments

Saul Wold - July 11, 2011, 11:13 p.m.
This class is for packages that do not work with debian library naming

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
 meta/classes/shared_lib.bbclass |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)
 create mode 100644 meta/classes/shared_lib.bbclass
Koen Kooi - July 12, 2011, 6:57 a.m.
Op 12 jul 2011, om 01:13 heeft Saul Wold het volgende geschreven:

> This class is for packages that do not work with debian library naming

If you put a single library in a package it *will* do shlib renaming. 

> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
> meta/classes/shared_lib.bbclass |    9 +++++++++

Can we name is sharedlib.bbclass or better shlibpackaging.bbclass?

> 1 files changed, 9 insertions(+), 0 deletions(-)
> create mode 100644 meta/classes/shared_lib.bbclass
> 
> diff --git a/meta/classes/shared_lib.bbclass b/meta/classes/shared_lib.bbclass
> new file mode 100644
> index 0000000..4237c8c
> --- /dev/null
> +++ b/meta/classes/shared_lib.bbclass
> @@ -0,0 +1,9 @@
> +#
> +# This bbclass it a common case for lib${PN} shared libraries
> +#
> +SUMMARY_lib${PN} ?= "${SUMMARY} - Shared Libraries"
> +DESCRIPTION_lib${PN} ?= "${DESCRIPTION} This package contains the shared libraries"
> +
> +PACKAGES += "lib${PN}"

I think you want =+ there

> +FILES_lib${PN} = "${libdir}/*${SOLIBS} ${base_libdir}/*${SOLIBS}"
> +RDEPENDS_lib${PN} = "${PN}"
> -- 
> 1.7.3.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - July 12, 2011, 9:11 a.m.
On Mon, 2011-07-11 at 16:13 -0700, Saul Wold wrote:
> This class is for packages that do not work with debian library naming

I tend to feel that most of those packages should be fixed so that they
do.  If they aren't currently getting renamed then it usually means that
they include too much (i.e. both binaries and libraries, or multiple
libraries) and should be split up so that this doesn't happen.

For the rare cases where you really do want to put multiple SOs in a
single output package you can use LEAD_SONAME, but this is virtually
never the right thing to do.

p.
Phil Blundell - July 12, 2011, 9:13 a.m.
On Tue, 2011-07-12 at 10:11 +0100, Phil Blundell wrote:
> On Mon, 2011-07-11 at 16:13 -0700, Saul Wold wrote:
> > This class is for packages that do not work with debian library naming
> 
> I tend to feel that most of those packages should be fixed so that they
> do.  If they aren't currently getting renamed then it usually means that
> they include too much (i.e. both binaries and libraries, or multiple
> libraries) and should be split up so that this doesn't happen.

Actually, looking at the patch more carefully I guess this does
basically address the first case above (binaries and libraries).  But it
looks like it will result in the slightly confusing situation where the
libraries go into lib${PN} but the corresponding headers are in
${PN}-dev.

p.
Saul Wold - July 12, 2011, 6:26 p.m.
On 07/12/2011 02:13 AM, Phil Blundell wrote:
> On Tue, 2011-07-12 at 10:11 +0100, Phil Blundell wrote:
>> On Mon, 2011-07-11 at 16:13 -0700, Saul Wold wrote:
>>> This class is for packages that do not work with debian library naming
>>
>> I tend to feel that most of those packages should be fixed so that they
>> do.  If they aren't currently getting renamed then it usually means that
>> they include too much (i.e. both binaries and libraries, or multiple
>> libraries) and should be split up so that this doesn't happen.
>
> Actually, looking at the patch more carefully I guess this does
> basically address the first case above (binaries and libraries).  But it
> looks like it will result in the slightly confusing situation where the
> libraries go into lib${PN} but the corresponding headers are in
> ${PN}-dev.
>
Correct, this is trying to address the existing cases that have both 
binaries and libraries, I guess the other way to do this would be for 
those 5 or so packages to use "lib_packaging" and which renames the 
binary packages ${PN}-bin and the libraries then get auto renamed via 
debian renaming rules.

This is kind of the inverse of lib_packaging.bbclass, binaries go in 
${PN} and libraries need to be placed into the named lib${PN}.

As for headers and debug, they go in the ${PN}-[dev,dbg] packagse

I can go with Koen's name of shlibpackaging.bbclass
Sau!

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

Patch

diff --git a/meta/classes/shared_lib.bbclass b/meta/classes/shared_lib.bbclass
new file mode 100644
index 0000000..4237c8c
--- /dev/null
+++ b/meta/classes/shared_lib.bbclass
@@ -0,0 +1,9 @@ 
+#
+# This bbclass it a common case for lib${PN} shared libraries
+#
+SUMMARY_lib${PN} ?= "${SUMMARY} - Shared Libraries"
+DESCRIPTION_lib${PN} ?= "${DESCRIPTION} This package contains the shared libraries"
+
+PACKAGES += "lib${PN}"
+FILES_lib${PN} = "${libdir}/*${SOLIBS} ${base_libdir}/*${SOLIBS}"
+RDEPENDS_lib${PN} = "${PN}"