From 750dc0a90438b48cabf552531e4e132e3a914782 Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Wed, 14 Mar 2007 22:24:43 +0000 Subject: class_autotools: Update the description of the site files to account for the changes to enable multiple site files, package specific site files, common site files and site file aliases. --- usermanual/reference/class_autotools.xml | 140 +++++++++++++++++++++++++------ 1 file changed, 115 insertions(+), 25 deletions(-) (limited to 'usermanual') diff --git a/usermanual/reference/class_autotools.xml b/usermanual/reference/class_autotools.xml index e4ed62ece0..25c32d8e50 100644 --- a/usermanual/reference/class_autotools.xml +++ b/usermanual/reference/class_autotools.xml @@ -25,7 +25,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/netcat/netcat-${PV}.tar.bz2" inherit autotoolsThe header is defined, the location of the source code and then the inherit. For the simplest cases this is all that is - required. If you need to pass additionol parameters to the configure script, + required. If you need to pass additional parameters to the configure script, such as for enabling and/or disabling options, then they can be specified via the EXTRA_OECONF variable. This example from the lftp recipe shows several extra options being passed to the configure @@ -75,10 +75,108 @@ do_install_append () { The autotools configuration method has support for caching the results of tests. In the cross-compilation case it is sometimes necessary - to prime the cache with pre-calculated results (since tests designed to + to prime the cache with per-calculated results (since tests designed to run on the target cannot be run when cross-compiling). These are defined - via the site file for the architecture you are using which is found in - org.openembedded.dev/site/<arch>-<target-os>. + via the site file(s) for the architecture you are using and may be + specific to the package you are building. + + Which site files are used is determined via the + classes/siteinfo.bbclass class file and you should + check that file to determine the names that apply to your target. + Typically the following site files will be checked for, and used if + found: + + + + endian-(big|little) + + + Either endian-big or + endian-little depending on the endianess of the + target. This site file would contain defines that only change based + on if the target is little endian or big endian. + + + + + bit-(32|64) + + + Either bit-32 or bit-64 + depending on the bitsize of the target. This site file would contain + defines that only change based on if the target is a 32-bit or + 64-bit cpu. + + + + + common-(libc|uclibc) + + + Either common-libc or + common-uclibc based on the C library being used + for the target. This site file would contain defines the are + specific to the C library being used. + + + + + <arch>-common + + + A common site file for the target architecture. For i386, + i485, i586 and i686 this would be x86-common, for + sh3 and sh4 this would be sh-common and for + various arm targets this would be + arm-common. + + + + + common + + + This is a site file which is common for all targets and + contains definitions which remain the same no matter what target is + being built. + + + + + Each of the supported site file for a target is checked for in + several locations, and each one found will be used in order. The following + locations are checked: + + + + org.openembedded.dev/packages/<packagename>/site-<version>/ + + + This directory is for site files which are specific to a + particular version (where version is the PV of the package) of a + package. + + + + + org.openembedded.dev/packages/<packagename>/site/ + + + This directory is for site files which are specific to a + particular package, but apply to all versions of the package. + + + + + org.openembedded.dev/site/ + + + This directory is for site files that are common to all + packages. Originally this was the only site file directory that was + supported. + + + There are some things that you should keep in mind about the caching of configure tests: @@ -125,27 +223,19 @@ do_install_append () { calling configure and it will then not be replaced by the value from the site file. - Sometimes it's useful to manually check values from the site file. - This can prove useful in situations where autotools is not used but you - still need some of the same information that an autotools configure script - would require. The following from the net-snmp recipe shows an example of - using the existing site file entries for endianess to pass the required - endianess option to the configure script:do_configure() { - # endianness fun.. inspired by openssl.inc - . ${CONFIG_SITE} - if [ "x$ac_cv_c_bigendian" = "xyes" -o "x$ac_cv_c_littleendian" = "xno" ]; then - ENDIANESS=" --with-endianness=big" - elif [ "x$ac_cv_c_littleendian" = "xyes" -o "x$ac_cv_c_bigendian" = "xno" ]; then - ENDIANESS=" --with-endianness=little" - else - oefatal do_configure cannot determine endianess - fi - oe_runconf $ENDIANESS -}It is also possible to disable the use of the cached values from the - site file by clearing the definition of CONFIG_SITE - prior to running the configure script. Doing this will disable the use of - the site file entirely. This however should be used as a last resort. The - following example from the db recipe shows an example of this:# Cancel the site stuff - it's set for db3 and destroys the + + Site files are applied in order, so the application specific site + files will be applied prior to the top level site file entries. The use + of conditional assignment means that the first definition found will + apply, while when not using conditionals the last definition found will + apply. + + + It is possible to disable the use of the cached values from the site + file by clearing the definition of CONFIG_SITE prior to + running the configure script. Doing this will disable the use of the site + file entirely. This however should be used as a last resort. The following + example from the db recipe shows an example of this:# Cancel the site stuff - it's set for db3 and destroys the # configure. CONFIG_SITE = "" do_configure() { -- cgit 1.2.3-korg From 845b0062935f20e90551cace2520e70f1ca4e5f6 Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Wed, 14 Mar 2007 23:29:45 +0000 Subject: usermanual: Add a siteinfo class section to the reference manual. Move the siteinfo class related stuff from the autotools class section into the siteuinfo class section and add details on the SITEINFO_ENDIANESS and SITEINFO_BITS variables. --- usermanual/reference/class_autotools.xml | 102 +----------------- usermanual/reference/class_siteinfo.xml | 180 +++++++++++++++++++++++++++++++ usermanual/usermanual.xml | 3 + 3 files changed, 188 insertions(+), 97 deletions(-) create mode 100644 usermanual/reference/class_siteinfo.xml (limited to 'usermanual') diff --git a/usermanual/reference/class_autotools.xml b/usermanual/reference/class_autotools.xml index 25c32d8e50..a9e1a5721a 100644 --- a/usermanual/reference/class_autotools.xml +++ b/usermanual/reference/class_autotools.xml @@ -80,103 +80,11 @@ do_install_append () { via the site file(s) for the architecture you are using and may be specific to the package you are building. - Which site files are used is determined via the - classes/siteinfo.bbclass class file and you should - check that file to determine the names that apply to your target. - Typically the following site files will be checked for, and used if - found: - - - - endian-(big|little) - - - Either endian-big or - endian-little depending on the endianess of the - target. This site file would contain defines that only change based - on if the target is little endian or big endian. - - - - - bit-(32|64) - - - Either bit-32 or bit-64 - depending on the bitsize of the target. This site file would contain - defines that only change based on if the target is a 32-bit or - 64-bit cpu. - - - - - common-(libc|uclibc) - - - Either common-libc or - common-uclibc based on the C library being used - for the target. This site file would contain defines the are - specific to the C library being used. - - - - - <arch>-common - - - A common site file for the target architecture. For i386, - i485, i586 and i686 this would be x86-common, for - sh3 and sh4 this would be sh-common and for - various arm targets this would be - arm-common. - - - - - common - - - This is a site file which is common for all targets and - contains definitions which remain the same no matter what target is - being built. - - - - - Each of the supported site file for a target is checked for in - several locations, and each one found will be used in order. The following - locations are checked: - - - - org.openembedded.dev/packages/<packagename>/site-<version>/ - - - This directory is for site files which are specific to a - particular version (where version is the PV of the package) of a - package. - - - - - org.openembedded.dev/packages/<packagename>/site/ - - - This directory is for site files which are specific to a - particular package, but apply to all versions of the package. - - - - - org.openembedded.dev/site/ - - - This directory is for site files that are common to all - packages. Originally this was the only site file directory that was - supported. - - - + Autoconf uses site files as definied in the + CONFIG_SITE variable, which is a space seperate list of + files to load in the specified order. Details on how this variable is set + is provided in the (the class + responsbile for setting the variable) section. There are some things that you should keep in mind about the caching of configure tests: diff --git a/usermanual/reference/class_siteinfo.xml b/usermanual/reference/class_siteinfo.xml new file mode 100644 index 0000000000..4d66e85e7c --- /dev/null +++ b/usermanual/reference/class_siteinfo.xml @@ -0,0 +1,180 @@ + +
+ siteinfo class + + The siteinfo class provides information for a target with a particular + emphasis on determining the names of the site files to be passed to + autoconf, as described in the . Full site + information for your target can be determined by looking at the table in the + class implementation found in the + classes/siteinfo.bbclass file. A typical entry contains + the name of the target and a list of site information for the + target: "sh4-linux": "endian-little bit-32 common-glibc sh-common",In + the above example for sh4-linux target (that's a build for an sh4 processor + using glibc) we see that the endianess and bit-size of target are defined + and an additional set of site files that should be used are listed. These + include a common site file for glibc and a common site file for sh + processors (so sh3 and sh4 can share defines). A "common" + entry is automatically added to the end of each of the definitions during + processing. + + The class makes available three variables based on the information + provided for a target: + + + + SITEINFO_ENDIANESS + + + Defines the endianess of the target as either + "le" (little endian) or "be" + (big endian). The target must list either + endian-little or endian-big in + it's site information. + + + + + SITEINFO_BITS + + + Defines the bitsize of the target as either + "32" or "64". The target must + list either bit-32 or bit-64 in + it's site information. + + + + + CONFIG_SITE + + + Defines the site files to be used by autoconf. This is a space + separated list of one or more site files for the target. + + + + + A typical use for the SITEINFO_ENDIANESS and + SITEINFO_BITS variables is to provide configuration + within a recipe based on their values. The following example from the + openssl recipe showw the correct define for the + endiness of the target being passed to openssl via the compiler flags. The + define to add to the flags is set based on the value of the + SITEINFO_ENDIANESS variable. Note that use of the + base_conditional method (see the section) to select a value conditional + on the endianess setting: + + # Additional flag based on target endiness (see siteinfo.bbclass) + CFLAG="${CFLAG} ${@base_conditional('SITEINFO_ENDIANESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)}" + +
+ CONFIG_SITE: The autoconf site files + + The autotools configuration method has support for caching the + results of tests. In the cross-compilation case it is sometimes necessary + to prime the cache with per-calculated results (since tests designed to + run on the target cannot be run when cross-compiling). These are defined + via the site file(s) for the architecture you are using and may be + specific to the package you are building. + + Which site files are used is determined via the + CONFIG_SITE definition which is calculated via the + siteinfo class. Typically the following site files will be checked for, + and used in the order found: + + + + endian-(big|little) + + + Either endian-big or + endian-little depending on the endianess of the + target. This site file would contain defines that only change based + on if the target is little endian or big endian. + + + + + bit-(32|64) + + + Either bit-32 or bit-64 + depending on the bitsize of the target. This site file would contain + defines that only change based on if the target is a 32-bit or + 64-bit cpu. + + + + + common-(libc|uclibc) + + + Either common-libc or + common-uclibc based on the C library being used + for the target. This site file would contain defines the are + specific to the C library being used. + + + + + <arch>-common + + + A common site file for the target architecture. For i386, + i485, i586 and i686 this would be x86-common, for + sh3 and sh4 this would be sh-common and for + various arm targets this would be + arm-common. + + + + + common + + + This is a site file which is common for all targets and + contains definitions which remain the same no matter what target is + being built. + + + + + Each of the supported site files for a target is will be checked for + in several different directories. Each time a file is found it as added to + the list of files in the CONFIG_SITE variable. The + following directories are checked: + + + + org.openembedded.dev/packages/<packagename>/site-<version>/ + + + This directory is for site files which are specific to a + particular version (where version is the PV of the package) of a + package. + + + + + org.openembedded.dev/packages/<packagename>/site/ + + + This directory is for site files which are specific to a + particular package, but apply to all versions of the package. + + + + + org.openembedded.dev/site/ + + + This directory is for site files that are common to all + packages. Originally this was the only site file directory that was + supported. + + + +
+
\ No newline at end of file diff --git a/usermanual/usermanual.xml b/usermanual/usermanual.xml index 8f9cdd53fd..e978dd50cc 100644 --- a/usermanual/usermanual.xml +++ b/usermanual/usermanual.xml @@ -17,6 +17,7 @@ + @@ -865,6 +866,8 @@ NOTE: Couldn't find shared library provider for libm.so.6 &var-section; + &class-siteinfo; + &var-src-uri; &class-update-alternatives; -- cgit 1.2.3-korg From 7b153a75335a572a2ba78bee5bf4a4c60f0c8c82 Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Thu, 15 Mar 2007 00:02:06 +0000 Subject: recipes: Fill out the section on DEFAULT_PREFERENCE. --- usermanual/chapters/recipes.xml | 67 ++++++++++++++++++++++++++++++----------- 1 file changed, 49 insertions(+), 18 deletions(-) (limited to 'usermanual') diff --git a/usermanual/chapters/recipes.xml b/usermanual/chapters/recipes.xml index 83c3f39279..786b80540c 100644 --- a/usermanual/chapters/recipes.xml +++ b/usermanual/chapters/recipes.xml @@ -2001,7 +2001,8 @@ NOTE: package helloworld-0.1-r0: task do_package_write: completedWe matched via wildcards. Consider the case where we have three binaries in the /usr/bin directory and we want the test program in a separate package:/usr/bin/programa /usr/bin/programb /usr/bin/testSo - we define a new package and instruct bitbake to /usr/bin/test in it. + we define a new package and instruct bitbake to /usr/bin/test in + it. FILES-${PN}-test = "${bindir}/test" PACKAGES += "FILES-${PN}-test" @@ -2019,7 +2020,8 @@ PACKAGES += "FILES-${PN}-test" processing of the ${PN}-test package. - To achieve what we are trying to accomplish we have two options: + To achieve what we are trying to accomplish we have two + options: @@ -3103,21 +3105,50 @@ do_configure() {
Preferences: How to disable packages - This section is to be completed. - - - - what DEFAULT_PREFERENCE does - - - - why you would want to use it - - - - using it with overrides - - + When bitbake is asked to build a package and multiple version of + that package are available it will normally select the version with the + highest version number (where the version is defined via the + PV variable). + + For example if we were to ask bitbake to build procps and the + following packages are available:~/oe%> ls packages/procps +procps-3.1.15/ procps-3.2.1/ procps-3.2.5/ procps-3.2.7/ procps.inc +procps_3.1.15.bb procps_3.2.1.bb procps_3.2.5.bb procps_3.2.7.bb +~/oe%>then we would expect that version 3.2.7 + (the highest version number) would be built. + + Sometimes this is not what you actually want to happen though. + Perhaps you have added a new version does not yet work or maybe the new + version has no support for your target yet. Help is at hand since bitbake + is not only looking at the version to decided which version to build but + is also looking at the preference for the versions, as defined via a + DEFAULT_PREFERENCE variable contained without the + recipes. + + By default DEFAULT_PREFERENCE is set to zero. + Bitbake will find the highest preference that is available and then for + all the packages at the preference level it will select the package with + the highest version. In general this means that adding a positive + DEFAULT_PREFERENCE will cause the package to be + preferred over other versions and a negative + DEFAULT_PREFERENCE will cause all other packages to be + preferred. + + Imagine that you are adding procps version 4.0.0, but that it does + not yet work. You could delete it to make procps build so you can build a + working image, but what you really want it just for version 4.0.0 to be + ignored until it works. By adding:DEFAULT_PREFERENCE = "-1"to + the recipe it'll cause it to be ignored by bitbake (since all the existing + versions have a preference of 0). Note that you can still call bitbake + directly on the recipe:bitbake -b packages/procps/procps_4.0.0.bbThis + enables you to test, and fix the package manually without having bitbake + automatically select normally. + + By using this in conjunction with overrides you can also disable (or + select) specific version for a specific architecture. The following + example from glibc shows that this version has been disabled for the sh3 + architecture because it doesn't support sh3. This will force bitbake to + try and select one of the other versions instead:packages/glibc/glibc_2.3.2+cvs20040726.bb:DEFAULT_PREFERENCE_sh3 = "-99"
@@ -3418,4 +3449,4 @@ which find
- + \ No newline at end of file -- cgit 1.2.3-korg From c5def93a47cd12c94f448c5531c89d2025bb20d2 Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Thu, 15 Mar 2007 06:50:22 +0000 Subject: recipes: Add details in the packaging section on how to avoid having to package up some files. --- usermanual/chapters/recipes.xml | 36 ++++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) (limited to 'usermanual') diff --git a/usermanual/chapters/recipes.xml b/usermanual/chapters/recipes.xml index 786b80540c..f4da35ba4d 100644 --- a/usermanual/chapters/recipes.xml +++ b/usermanual/chapters/recipes.xml @@ -1999,9 +1999,9 @@ NOTE: package helloworld-0.1-r0: task do_package_write: completedWe Note that the order of packages effects the files that will be matched via wildcards. Consider the case where we have three binaries in - the /usr/bin directory and we want the test program in a separate - package:/usr/bin/programa /usr/bin/programb /usr/bin/testSo - we define a new package and instruct bitbake to /usr/bin/test in + the /usr/bin directory and we want the test program + in a separate package:/usr/bin/programa /usr/bin/programb /usr/bin/testSo + we define a new package and instruct bitbake to include /usr/bin/test in it. FILES-${PN}-test = "${bindir}/test" @@ -2113,6 +2113,34 @@ NOTE: package helloworld-0.1-r0: task do_package: completedExcept in behind by a recipe. +
+ Excluding files + + There's no actual support for explicitly excluding files from + packaging. You could just leave them out of any package, but then you'll + get warnings (or errors if requesting full package checking) during + packaging which is not desirable. It also doesn't let other people know + that you've deliberately avoided packaging the file or files. + + In order to exclude a file totally you should avoid installing it + in the first place during the install task. + + In some cases it may be easier to let the package install the file + and then explicitly remove the file and the end of the install task. The + following example from the samba recipe shows the removal of several + files that get installed via the default install task generated by the + . By using + do_install_append these commands and run after the + autotools generated install task: + + do_install_append() { + ... + rm -f ${D}${bindir}/*.old + rm -f ${D}${sbindir}/*.old + ... +} +
+
Debian naming @@ -3108,7 +3136,7 @@ do_configure() { When bitbake is asked to build a package and multiple version of that package are available it will normally select the version with the highest version number (where the version is defined via the - PV variable). + PV variable). For example if we were to ask bitbake to build procps and the following packages are available:~/oe%> ls packages/procps -- cgit 1.2.3-korg From 55b9739d22ea4763397a710c84c5d98be536bf26 Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Thu, 15 Mar 2007 07:02:23 +0000 Subject: recipes: Update the sample package output to show that packages now go into deploy/ipkg/ rather than just deploy/ipkg to reflect recent changes. --- usermanual/chapters/recipes.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'usermanual') diff --git a/usermanual/chapters/recipes.xml b/usermanual/chapters/recipes.xml index f4da35ba4d..3462c11acc 100644 --- a/usermanual/chapters/recipes.xml +++ b/usermanual/chapters/recipes.xml @@ -1212,8 +1212,8 @@ NOTE: package helloworld-0.1-r0: task do_package: started NOTE: package helloworld-0.1-r0: task do_package: completed NOTE: package helloworld-0.1-r0: task do_package_write: started NOTE: Not creating empty archive for helloworld-dbg-0.1-r0 -Packaged contents of helloworld into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/helloworld_0.1-r0_sh4.ipk -Packaged contents of helloworld-doc into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/helloworld-doc_0.1-r0_sh4.ipk +Packaged contents of helloworld into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/sh4/helloworld_0.1-r0_sh4.ipk +Packaged contents of helloworld-doc into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/sh4/helloworld-doc_0.1-r0_sh4.ipk NOTE: Not creating empty archive for helloworld-dev-0.1-r0 NOTE: Not creating empty archive for helloworld-locale-0.1-r0 NOTE: package helloworld-0.1-r0: task do_package_write: completed @@ -1228,9 +1228,9 @@ Build statistics: The package was successfully built, the output consists of two .ipkg files, which are ready to be installed on the target. One contains - the binary and the other contains the readme file:~/oe%> ls -l tmp/deploy/ipk/helloworld* --rw-r--r-- 1 lenehan lenehan 3040 Jan 12 14:46 tmp/deploy/ipk/helloworld_0.1-r0_sh4.ipk --rw-r--r-- 1 lenehan lenehan 768 Jan 12 14:46 tmp/deploy/ipk/helloworld-doc_0.1-r0_sh4.ipk + the binary and the other contains the readme file:~/oe%> ls -l tmp/deploy/ipk/*/helloworld* +-rw-r--r-- 1 lenehan lenehan 3040 Jan 12 14:46 tmp/deploy/ipk/sh4/helloworld_0.1-r0_sh4.ipk +-rw-r--r-- 1 lenehan lenehan 768 Jan 12 14:46 tmp/deploy/ipk/sh4/helloworld-doc_0.1-r0_sh4.ipk ~/oe%> It's worthwhile looking at the working directory to see where @@ -1714,8 +1714,8 @@ inherit autotools example of the packaging output from the helloworld example above shows this packaging in action:[NOTE: package helloworld-0.1-r0: task do_package_write: started NOTE: Not creating empty archive for helloworld-dbg-0.1-r0 -Packaged contents of helloworld into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/helloworld_0.1-r0_sh4.ipk -Packaged contents of helloworld-doc into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/helloworld-doc_0.1-r0_sh4.ipk +Packaged contents of helloworld into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/sh4/helloworld_0.1-r0_sh4.ipk +Packaged contents of helloworld-doc into /home/lenehan/devel/oe/build/titan-glibc-25/tmp/deploy/ipk/sh4/helloworld-doc_0.1-r0_sh4.ipk NOTE: Not creating empty archive for helloworld-dev-0.1-r0 NOTE: Not creating empty archive for helloworld-locale-0.1-r0 NOTE: package helloworld-0.1-r0: task do_package_write: completedWe -- cgit 1.2.3-korg From bd223c6d29f2bc1b6fda88dcbaab5d02d01ab76e Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Fri, 16 Mar 2007 00:08:57 +0000 Subject: reference/dirs_staging: Update some paths to match recent change make to bitbake.conf. --- usermanual/reference/dirs_staging.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'usermanual') diff --git a/usermanual/reference/dirs_staging.xml b/usermanual/reference/dirs_staging.xml index c9ab09fbec..25f3685aad 100644 --- a/usermanual/reference/dirs_staging.xml +++ b/usermanual/reference/dirs_staging.xml @@ -79,7 +79,7 @@ STAGING_BINDIR - ${STAGING_DIR}/${BUILD_SYS}/bin + ${STAGING_DIR}/${HOST_SYS}/bin @@ -139,7 +139,7 @@ PKG_CONFIG_PATH - ${STAGING_DATADIR}/pkgconfig + ${STAGING_LIBDIR}/pkgconfig -- cgit 1.2.3-korg From c154e4300447e50c7e56f180739b7e76329ac5e1 Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Fri, 16 Mar 2007 00:19:12 +0000 Subject: recipes: Update the note about the PR variable making it clear that it never goes backwards and that you should always increase it if you are unsure about what effect it has on the generated packages. --- usermanual/chapters/recipes.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'usermanual') diff --git a/usermanual/chapters/recipes.xml b/usermanual/chapters/recipes.xml index 3462c11acc..f889acd395 100644 --- a/usermanual/chapters/recipes.xml +++ b/usermanual/chapters/recipes.xml @@ -335,6 +335,17 @@ mv fixed.recipe.bb myrecipe.bb It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated. + + You should always increment PR when modifying a recipe. + Sometimes this can be avoided if the change will have no effect on the + actual packages generated by the recipe, such as updating the SRC_URI + to point to a new host. If in any doubt then you should increase the + PR regardless of what has been changed. + + The PR value should never be decremented. If you accidentally + submit a large PR value for example then it should be left at the + value and just increased for new releases, not reset back to a lower + version. When a recipe is being processed some variables are automatically -- cgit 1.2.3-korg From 60a8d23752b2e0ffe9aeb2c4220ab7a1bb5f10eb Mon Sep 17 00:00:00 2001 From: Jamie Lenehan Date: Sat, 17 Mar 2007 00:25:05 +0000 Subject: recipes: Fill in some details on the debian library policy in the packing section. --- usermanual/chapters/recipes.xml | 80 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 73 insertions(+), 7 deletions(-) (limited to 'usermanual') diff --git a/usermanual/chapters/recipes.xml b/usermanual/chapters/recipes.xml index f889acd395..7ed33868f5 100644 --- a/usermanual/chapters/recipes.xml +++ b/usermanual/chapters/recipes.xml @@ -345,7 +345,7 @@ mv fixed.recipe.bb myrecipe.bb The PR value should never be decremented. If you accidentally submit a large PR value for example then it should be left at the value and just increased for new releases, not reset back to a lower - version. + version. When a recipe is being processed some variables are automatically @@ -2155,13 +2155,79 @@ NOTE: package helloworld-0.1-r0: task do_package: completedExcept in
Debian naming - This section is to be completed + A special debian library name policy can be + applied for packages that contain a single shared library. When enabled + packages will be renamed to match the debian policy for such + packages. + + Debian naming is enabled by including the debian class via either + local.conf or your distributions configuration + file:INHERIT += "debian" + + The policy works by looking at the shared library name and version + and will automatically rename the package to + <libname><lib-major-version>. For + example if the package name (PN) is foo and the + package ships a file named libfoo.so.1.2.3 then the + package will be renamed to libfoo1 to follow the + debian policy. + + If we look at the lzo_1.08.bb recipe, + currently at release 14, it generates a package containing a single + shared library :~oe/build/titan-glibc-25%> find tmp/work/lzo-1.08-r14/install/ +tmp/work/lzo-1.08-r14/install/lzo +tmp/work/lzo-1.08-r14/install/lzo/usr +tmp/work/lzo-1.08-r14/install/lzo/usr/lib +tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1 +tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0Without + debian naming this package would have been called + lzo_1.08-r14_sh4.ipk (and the corresponding dev and + dbg packages would have been called + lzo-dbg_1.08-r14_sh4.ipk and + lzo-dev_1.08-r14_sh4.ipk). However with debian naming + enabled the package is renamed based on the name of the shared library, + which is liblzo.so.1.0.0 in this case. So the name + lzo is replaced with + liblzo1:~oe/build/titan-glibc-25%> find tmp/deploy/ipk/ -name '*lzo*' +tmp/deploy/ipk/sh4/liblzo1_1.08-r14_sh4.ipk +tmp/deploy/ipk/sh4/liblzo-dev_1.08-r14_sh4.ipk +tmp/deploy/ipk/sh4/liblzo-dbg_1.08-r14_sh4.ipk + + Some variables are available which effect the operation of the + debian renaming class: - - - inherit += "debian" - - + + + LEAD_SONAME + + + If the package actually contains multiple shared libraries + then one will be selected automatically and a warning will be + generated. This variable is a regular expression which is used to + select which shared library from those available is to be used for + debian renaming. + + + + + DEBIAN_NOAUTONAME_<pkgname> + + + If this variable is set to 1 for a package then debian + renaming will not be applied for the package. + + + + + AUTO_LIBNAME_PKGS + + + If set this variable specifies the prefix of packages which + will be subject to debian renaming. This can be used to prevent + all of the packages being renamed via the renaming policy. + + +
-- cgit 1.2.3-korg