diff options
Diffstat (limited to 'usermanual/usermanual.xml')
| -rw-r--r-- | usermanual/usermanual.xml | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/usermanual/usermanual.xml b/usermanual/usermanual.xml index 6e996881f3..34417379dc 100644 --- a/usermanual/usermanual.xml +++ b/usermanual/usermanual.xml @@ -111,7 +111,7 @@ SRC_URI = "http://www.host.com/foo/files/${P}.tar.bz2;md5sum=yoursum" </screen> -This will tell the fetcher to where to download the sources from and it will check the integrity using md5sum if you provided the appropriate <emphasis>yoursum</emphasis>. You can make one by doing <screen>md5sum foo-3.2.2.tar.gz</screen> and replacing <emphasis>yoursum</emphasis> with the md5sum on your screen. A typical md5sum will look like this: <screen>a6434b0fc8a54c3dec3d6875bf3be8db</screen>. Notice the <emphasis>${P}</emphasis> variable, that one holds the package name, <emphasis>${PN}</emphasis> in bitbake speak and the package version, <emphasis>${PV}</emphasis> in bitbake speak. It's a short way of writing <emphasis>${PN}-${PV}</emphasis>. Using this notation means you can copy the recipe when a new version is released without having to alter the contents. You do need to check if everything is still correct, because new versions mean new bugs. +This will tell the fetcher to where to download the sources from and it will check the integrity using md5sum if you provided the appropriate <emphasis>yoursum</emphasis>. You can make one by doing <screen>md5sum foo-3.2.2.tar.gz</screen> and replacing <emphasis>yoursum</emphasis> with the md5sum on your screen. A typical md5sum will look like this: <screen>a6434b0fc8a54c3dec3d6875bf3be8db </screen>Notice the <emphasis>${P}</emphasis> variable, that one holds the package name, <emphasis>${PN}</emphasis> in bitbake speak and the package version, <emphasis>${PV}</emphasis> in bitbake speak. It's a short way of writing <emphasis>${PN}-${PV}</emphasis>. Using this notation means you can copy the recipe when a new version is released without having to alter the contents. You do need to check if everything is still correct, because new versions mean new bugs. Before we can move to the actual building we need to find out which build system the package is using. If we're lucky, we see a <emphasis>configure</emphasis> file in the build tree this is an indicator that we can <emphasis>inherit autotools</emphasis> if we see a <emphasis>.pro</emphasis> file, it might be qmake, which needs <emphasis>inherit qmake</emphasis>. Virtually all gtk apps use autotools: |