dev-manual: Reorganization for section using libraries
Fixes YOCTO #1548 Created a new section called "Working With Libraries". This section is a parent section for all the stuff about libraries. Previously, there were two other sections dealing with libraries: one was mulitlib section and one was about loading static libraries. It makes sense to have a parent section now that gathers the three sub-sections together. I have reorganized the chapter structure to accomplish this. Also, I placed some IRC chat notes temporarily into the new section that will discuss how to load multiple versions of the same library in parallel on the system. (From yocto-docs rev: 5d150421bcd660a191aff63ebabd577cc19bd421) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
ef0ef862c1
commit
d0edd46ebb
|
|
@ -981,61 +981,6 @@
|
|||
</para>
|
||||
</section>
|
||||
|
||||
<section id='including-static-library-files'>
|
||||
<title>Including Static Library Files</title>
|
||||
|
||||
<para>
|
||||
If you are building a library and the library offers static linking, you can control
|
||||
which static library files (<filename>*.a</filename> files) get included in the
|
||||
built library.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
|
||||
and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
|
||||
variables in the
|
||||
<filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
|
||||
by the <filename>do_install</filename> task are packaged.
|
||||
By default, the <filename>PACKAGES</filename> variable contains
|
||||
<filename>${PN}-staticdev</filename>, which includes all static library files.
|
||||
<note>
|
||||
Previously released versions of the Yocto Project defined the static library files
|
||||
through <filename>${PN}-dev</filename>.
|
||||
</note>
|
||||
Following, is part of the BitBake configuration file.
|
||||
You can see where the static library files are defined:
|
||||
<literallayout class='monospaced'>
|
||||
PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
|
||||
PACKAGES_DYNAMIC = "${PN}-locale-*"
|
||||
FILES = ""
|
||||
|
||||
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
|
||||
${sysconfdir} ${sharedstatedir} ${localstatedir} \
|
||||
${base_bindir}/* ${base_sbindir}/* \
|
||||
${base_libdir}/*${SOLIBS} \
|
||||
${datadir}/${BPN} ${libdir}/${BPN}/* \
|
||||
${datadir}/pixmaps ${datadir}/applications \
|
||||
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
|
||||
${libdir}/bonobo/servers"
|
||||
|
||||
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
|
||||
${datadir}/gnome/help"
|
||||
SECTION_${PN}-doc = "doc"
|
||||
|
||||
FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
|
||||
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
|
||||
${datadir}/aclocal ${base_libdir}/*.o"
|
||||
SECTION_${PN}-dev = "devel"
|
||||
ALLOW_EMPTY_${PN}-dev = "1"
|
||||
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
|
||||
|
||||
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
|
||||
SECTION_${PN}-staticdev = "devel"
|
||||
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='usingpoky-extend-addpkg-postinstalls'>
|
||||
<title>Post Install Scripts</title>
|
||||
|
||||
|
|
@ -1235,7 +1180,69 @@
|
|||
</section>
|
||||
</section>
|
||||
|
||||
<section id="building-multiple-architecture-libraries-into-one-image">
|
||||
<section id="platdev-working-with-libraries">
|
||||
<title>Working With Libraries</title>
|
||||
|
||||
<para>
|
||||
Intro text
|
||||
</para>
|
||||
|
||||
<section id='including-static-library-files'>
|
||||
<title>Including Static Library Files</title>
|
||||
|
||||
<para>
|
||||
If you are building a library and the library offers static linking, you can control
|
||||
which static library files (<filename>*.a</filename> files) get included in the
|
||||
built library.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
|
||||
and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
|
||||
variables in the
|
||||
<filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
|
||||
by the <filename>do_install</filename> task are packaged.
|
||||
By default, the <filename>PACKAGES</filename> variable contains
|
||||
<filename>${PN}-staticdev</filename>, which includes all static library files.
|
||||
<note>
|
||||
Previously released versions of the Yocto Project defined the static library files
|
||||
through <filename>${PN}-dev</filename>.
|
||||
</note>
|
||||
Following, is part of the BitBake configuration file.
|
||||
You can see where the static library files are defined:
|
||||
<literallayout class='monospaced'>
|
||||
PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
|
||||
PACKAGES_DYNAMIC = "${PN}-locale-*"
|
||||
FILES = ""
|
||||
|
||||
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
|
||||
${sysconfdir} ${sharedstatedir} ${localstatedir} \
|
||||
${base_bindir}/* ${base_sbindir}/* \
|
||||
${base_libdir}/*${SOLIBS} \
|
||||
${datadir}/${BPN} ${libdir}/${BPN}/* \
|
||||
${datadir}/pixmaps ${datadir}/applications \
|
||||
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
|
||||
${libdir}/bonobo/servers"
|
||||
|
||||
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
|
||||
${datadir}/gnome/help"
|
||||
SECTION_${PN}-doc = "doc"
|
||||
|
||||
FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
|
||||
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
|
||||
${datadir}/aclocal ${base_libdir}/*.o"
|
||||
SECTION_${PN}-dev = "devel"
|
||||
ALLOW_EMPTY_${PN}-dev = "1"
|
||||
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
|
||||
|
||||
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
|
||||
SECTION_${PN}-staticdev = "devel"
|
||||
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="combining-multiple-versions-library-files-into-one-image">
|
||||
<title>Combining Multiple Versions of Library Files into One Image</title>
|
||||
|
||||
<para>
|
||||
|
|
@ -1421,6 +1428,37 @@
|
|||
</section>
|
||||
</section>
|
||||
|
||||
<section id='installing-multiple-versions-of-the-same-library'>
|
||||
<title>Installing Multiple Versions of the Same Library</title>
|
||||
|
||||
<para>
|
||||
<literallayout class='monospaced'>
|
||||
(08:04:38 AM) scottrif: RP: I am looking at an old bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=1548) regarding documenting how multiple different library versions of a library can be built and installed in parallel on a system. You mention Clutter as a good example of this. Before I start diving into this can you tell me if it is still relevant given the bug was filed in Oct. of 2011?
|
||||
(08:06:44 AM) paul.eggleton: scottrif: it's still a valid use case I think
|
||||
(08:06:59 AM) scottrif: paul.eggleton: ok - thanks
|
||||
(08:07:43 AM) paul.eggleton: it's not too tricky assuming the library uses proper versioning itself; if it does you just need to ensure something version-specific appears in PN
|
||||
(08:08:07 AM) paul.eggleton: so e.g. for clutter, PN is clutter-1.8 rather than just clutter
|
||||
(08:09:25 AM) scottrif: paul.eggleton: so PN specifies version 1.8 in your example. Do you put multiple PN statements somewhere to accomplish installing multiple versions of the same library?
|
||||
(08:09:52 AM) paul.eggleton: scottrif: no, you need to provide a separate recipe for each version
|
||||
(08:09:59 AM) paul.eggleton: scottrif: so the PN would come from the file name
|
||||
(08:10:07 AM) paul.eggleton: (as normal)
|
||||
(08:10:24 AM) paul.eggleton: so e.g. the recipe might be clutter-1.8_1.8.4.bb
|
||||
(08:10:30 AM) scottrif: paul.eggleton: ok - one version per library version and each recipe specifically uses PN to indicate the version.
|
||||
(08:10:48 AM) paul.eggleton: the major part of the version, yes
|
||||
(08:10:48 AM) scottrif: paul.eggleton: I mean one "recipe" per library version :)
|
||||
(08:11:18 AM) scottrif: paul.eggleton: major being "1.8" in your example
|
||||
(08:11:33 AM) paul.eggleton: right, in this instance one recipe per major version since the API got changed between the two
|
||||
(08:11:56 AM) paul.eggleton: (which is the typical cause of needing to do this multiple version exercise)
|
||||
(08:12:15 AM) scottrif: paul.eggleton: okay - so what circumstances do I tell the reader when it is a good idea to do this besides the case you just stated?
|
||||
(08:14:07 AM) paul.eggleton: it's almost always about an API change and you have other pieces of software that depend on both versions that you need to build and use at runtime within the same system
|
||||
(08:14:22 AM) paul.eggleton: in fact I can't think of another reason why you'd want to do this
|
||||
(08:14:44 AM) scottrif: paul.eggleton: ok - I will stick to that one. Thanks! I will probably enlist you to check over the new section :)
|
||||
(08:14:52 AM) paul.eggleton: scottrif: sure thing
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='configuring-the-kernel'>
|
||||
<title>Configuring the Kernel</title>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue