summaryrefslogtreecommitdiffstats
path: root/bitbake/doc
diff options
context:
space:
mode:
Diffstat (limited to 'bitbake/doc')
-rw-r--r--bitbake/doc/manual/usermanual.xml136
1 files changed, 108 insertions, 28 deletions
diff --git a/bitbake/doc/manual/usermanual.xml b/bitbake/doc/manual/usermanual.xml
index 7dea949f4f..4f6725fd61 100644
--- a/bitbake/doc/manual/usermanual.xml
+++ b/bitbake/doc/manual/usermanual.xml
@@ -12,9 +12,10 @@
12 <corpauthor>BitBake Team</corpauthor> 12 <corpauthor>BitBake Team</corpauthor>
13 </authorgroup> 13 </authorgroup>
14 <copyright> 14 <copyright>
15 <year>2004, 2005, 2006</year> 15 <year>2004, 2005, 2006, 2011</year>
16 <holder>Chris Larson</holder> 16 <holder>Chris Larson</holder>
17 <holder>Phil Blundell</holder> 17 <holder>Phil Blundell</holder>
18 <holder>Richard Purdie</holder>
18 </copyright> 19 </copyright>
19 <legalnotice> 20 <legalnotice>
20 <para>This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit <ulink url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</ulink> or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.</para> 21 <para>This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit <ulink url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</ulink> or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.</para>
@@ -26,7 +27,7 @@
26 <title>Overview</title> 27 <title>Overview</title>
27 <para>BitBake is, at its simplest, a tool for executing 28 <para>BitBake is, at its simplest, a tool for executing
28tasks and managing metadata. As such, its similarities to GNU make and other 29tasks and managing metadata. As such, its similarities to GNU make and other
29build tools are readily apparent. It was inspired by Portage, the package management system used by the Gentoo Linux distribution. BitBake is the basis of the <ulink url="http://www.openembedded.org/">OpenEmbedded</ulink> project, which is being used to build and maintain a number of embedded Linux distributions, including OpenZaurus and Familiar.</para> 30build tools are readily apparent. It was inspired by Portage, the package management system used by the Gentoo Linux distribution. BitBake is the basis of the <ulink url="http://www.openembedded.org/">OpenEmbedded</ulink> project, which is being used to build and maintain a number of embedded Linux distributions/projects such as Angstrom and the Yocto project.</para>
30 </section> 31 </section>
31 <section> 32 <section>
32 <title>Background and goals</title> 33 <title>Background and goals</title>
@@ -37,7 +38,7 @@ important functionality, and none of the ad-hoc
37<emphasis>buildroot</emphasis> systems, prevalent in the 38<emphasis>buildroot</emphasis> systems, prevalent in the
38embedded space, were scalable or maintainable.</para> 39embedded space, were scalable or maintainable.</para>
39 40
40 <para>Some important goals for BitBake were: 41 <para>Some important original goals for BitBake were:
41 <itemizedlist> 42 <itemizedlist>
42 <listitem><para>Handle crosscompilation.</para></listitem> 43 <listitem><para>Handle crosscompilation.</para></listitem>
43 <listitem><para>Handle interpackage dependencies (build time on target architecture, build time on native architecture, and runtime).</para></listitem> 44 <listitem><para>Handle interpackage dependencies (build time on target architecture, build time on native architecture, and runtime).</para></listitem>
@@ -53,10 +54,18 @@ between multiple projects using BitBake for their
53builds.</para></listitem> 54builds.</para></listitem>
54 <listitem><para>Should provide an inheritance mechanism to 55 <listitem><para>Should provide an inheritance mechanism to
55share common metadata between many packages.</para></listitem> 56share common metadata between many packages.</para></listitem>
56 <listitem><para>Et cetera...</para></listitem>
57 </itemizedlist> 57 </itemizedlist>
58 </para> 58 </para>
59 <para>BitBake satisfies all these and many more. Flexibility and power have always been the priorities. It is highly extensible, supporting embedded Python code and execution of any arbitrary tasks.</para> 59 <para>Over time it has become apparent that some further requirements were necessary:
60 <itemizedlist>
61 <listitem><para>Handle variants of a base recipe (native, sdk, multilib).</para></listitem>
62 <listitem><para>Able to split metadata into layers and allow layers to override each other.</para></listitem>
63 <listitem><para>Allow representation of a given set of input variables to a task as a checksum.</para></listitem>
64 <listitem><para>based on that checksum, allow acceleration of builds with prebuilt components.</para></listitem>
65 </itemizedlist>
66 </para>
67
68 <para>BitBake satisfies all the original requirements and many more with extensions being made to the basic functionality to reflect the additionl requirements. Flexibility and power have always been the priorities. It is highly extensible, supporting embedded Python code and execution of any arbitrary tasks.</para>
60 </section> 69 </section>
61 </chapter> 70 </chapter>
62 <chapter> 71 <chapter>
@@ -94,10 +103,10 @@ share common metadata between many packages.</para></listitem>
94 <para>If <varname>A</varname> is set before the above is called, it will retain its previous value. If <varname>A</varname> is unset prior to the above call, <varname>A</varname> will be set to <literal>aval</literal>. Note that this assignment is immediate, so if there are multiple ?= assignments to a single variable, the first of those will be used.</para> 103 <para>If <varname>A</varname> is set before the above is called, it will retain its previous value. If <varname>A</varname> is unset prior to the above call, <varname>A</varname> will be set to <literal>aval</literal>. Note that this assignment is immediate, so if there are multiple ?= assignments to a single variable, the first of those will be used.</para>
95 </section> 104 </section>
96 <section> 105 <section>
97 <title>Setting a default value (??=)</title> 106 <title>Setting a weak default value (??=)</title>
98 <para><screen><varname>A</varname> ??= "somevalue"</screen></para> 107 <para><screen><varname>A</varname> ??= "somevalue"
99 <para><screen><varname>A</varname> ??= "someothervalue"</screen></para> 108<varname>A</varname> ??= "someothervalue"</screen></para>
100 <para>If <varname>A</varname> is set before the above, it will retain that value. If <varname>A</varname> is unset prior to the above, <varname>A</varname> will be set to <literal>someothervalue</literal>. This is a lazy version of ??=, in that the assignment does not occur until the end of the parsing process, so that the last, rather than the first, ??= assignment to a given variable will be used.</para> 109 <para>If <varname>A</varname> is set before the above, it will retain that value. If <varname>A</varname> is unset prior to the above, <varname>A</varname> will be set to <literal>someothervalue</literal>. This is a lazy/weak assignment in that the assignment does not occur until the end of the parsing process, so that the last, rather than the first, ??= assignment to a given variable will be used. Any other setting of A using = or ?= will however override the value set with ??=</para>
101 </section> 110 </section>
102 <section> 111 <section>
103 <title>Immediate variable expansion (:=)</title> 112 <title>Immediate variable expansion (:=)</title>
@@ -209,6 +218,19 @@ include</literal> directive.</para>
209addtask printdate before do_build</screen></para> 218addtask printdate before do_build</screen></para>
210 <para>This defines the necessary Python function and adds it as a task which is now a dependency of do_build, the default task. If anyone executes the do_build task, that will result in do_printdate being run first.</para> 219 <para>This defines the necessary Python function and adds it as a task which is now a dependency of do_build, the default task. If anyone executes the do_build task, that will result in do_printdate being run first.</para>
211 </section> 220 </section>
221
222 <section>
223 <title>Task Flags</title>
224 <para>Tasks support a number of flags which control various functionality of the task. These are as follows:</para>
225 <para>'dirs' - directories which should be created before the task runs</para>
226 <para>'cleandirs' - directories which should created before the task runs but should be empty</para>
227 <para>'noexec' - marks the tasks as being empty and no execution required. These are used as dependency placeholders or used when added tasks need to be subsequently disabled.</para>
228 <para>'nostamp' - don't generate a stamp file for a task. This means the task is always rexecuted.</para>
229 <para>'fakeroot' - this task needs to be run in a fakeroot environment, obtained by adding the variables in FAKEROOTENV to the environment.</para>
230 <para>'umask' - the umask to run the task under.</para>
231 <para> For the 'deptask', 'rdeptask', 'recdeptask' and 'recrdeptask' flags please see the dependencies section.</para>
232 </section>
233
212 <section> 234 <section>
213 <title>Events</title> 235 <title>Events</title>
214 <para><emphasis>NOTE:</emphasis> This is only supported in .bb and .bbclass files.</para> 236 <para><emphasis>NOTE:</emphasis> This is only supported in .bb and .bbclass files.</para>
@@ -239,6 +261,51 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
239 <para>Note that the name of the range will default to the original version of the recipe, so given OE, a recipe file of foo_1.0.0+.bb will default the name of its versions to 1.0.0+. This is useful, as the range name is not only placed into overrides; it's also made available for the metadata to use in the form of the <varname>BPV</varname> variable, for use in file:// search paths (<varname>FILESPATH</varname>).</para> 261 <para>Note that the name of the range will default to the original version of the recipe, so given OE, a recipe file of foo_1.0.0+.bb will default the name of its versions to 1.0.0+. This is useful, as the range name is not only placed into overrides; it's also made available for the metadata to use in the form of the <varname>BPV</varname> variable, for use in file:// search paths (<varname>FILESPATH</varname>).</para>
240 </section> 262 </section>
241 </section> 263 </section>
264
265 <section>
266 <title>Variable interaction: Worked Examples</title>
267 <para>Despite the documentation of the different forms of variable definition above, it can be hard to work out what happens when variable operators are combined. This section documents some common questions people have regarding the way variables interact.</para>
268
269 <section>
270 <title>Override and append ordering</title>
271
272 <para>There is often confusion about which order overrides and the various append operators take effect.</para>
273
274 <para><screen><varname>OVERRIDES</varname> = "foo"
275<varname>A_foo_append</varname> = "X"</screen></para>
276 <para>In this case, X is unconditionally appended to the variable <varname>A_foo</varname>. Since foo is an override, A_foo would then replace <varname>A</varname>.</para>
277
278 <para><screen><varname>OVERRIDES</varname> = "foo"
279<varname>A</varname> = "X"
280<varname>A_append_foo</varname> = "Y"</screen></para>
281 <para>In this case, only when foo is in OVERRIDES, Y is appended to the variable <varname>A</varname> so the value of <varname>A</varname> would become XY (NB: no spaces are appended).</para>
282
283 <para><screen><varname>OVERRIDES</varname> = "foo"
284<varname>A_foo_append</varname> = "X"
285<varname>A_foo_append</varname> += "Y"</screen></para>
286 <para>This behaves as per the first case above, but the value of <varname>A</varname> would be "X Y" instead of just "X".</para>
287
288 <para><screen><varname>A</varname> = "1"
289<varname>A_append</varname> = "2"
290<varname>A_append</varname> = "3"
291<varname>A</varname> += "4"
292<varname>A</varname> .= "5"</screen></para>
293
294 <para>Would ultimately result in <varname>A</varname> taking the value "1 4523" since the _append operator executes at the same time as the expansion of other overrides.</para>
295
296 </section>
297 <section>
298 <title>Key Expansion</title>
299
300 <para>Key expansion happens at the data store finalisation time just before overrides are expanded.</para>
301
302 <para><screen><varname>A${B}</varname> = "X"
303<varname>B</varname> = "2"
304<varname>A2</varname> = "Y"</screen></para>
305 <para>So in this case <varname>A2</varname> would take the value of "X".</para>
306 </section>
307
308 </section>
242 <section> 309 <section>
243 <title>Dependency handling</title> 310 <title>Dependency handling</title>
244 <para>BitBake 1.7.x onwards works with the metadata at the task level since this is optimal when dealing with multiple threads of execution. A robust method of specifing task dependencies is therefore needed. </para> 311 <para>BitBake 1.7.x onwards works with the metadata at the task level since this is optimal when dealing with multiple threads of execution. A robust method of specifing task dependencies is therefore needed. </para>
@@ -299,13 +366,35 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
299 <title>File download support</title> 366 <title>File download support</title>
300 <section> 367 <section>
301 <title>Overview</title> 368 <title>Overview</title>
302 <para>BitBake provides support to download files this procedure is called fetching. The SRC_URI is normally used to tell BitBake which files to fetch. The next sections will describe the available fetchers and their options. Each fetcher honors a set of variables and per URI parameters separated by a <quote>;</quote> consisting of a key and a value. The semantics of the variables and parameters are defined by the fetcher. BitBake tries to have consistent semantics between the different fetchers. 369 <para>BitBake provides support to download files this procedure is called fetching and it handled by the fetch and fetch2 modules. At this point the original fetch code is considered to be replaced by fetch2 and this manual only related to the fetch2 codebase.</para>
370
371 <para>The SRC_URI is normally used to tell BitBake which files to fetch. The next sections will describe the available fetchers and their options. Each fetcher honors a set of variables and per URI parameters separated by a <quote>;</quote> consisting of a key and a value. The semantics of the variables and parameters are defined by the fetcher. BitBake tries to have consistent semantics between the different fetchers.
303 </para> 372 </para>
373
374 <para>The overall fetch process is that first, fetches are attempted from PREMIRRORS. If those don't work, the original SRC_URI is attempted and if that fails, BitBake will fall back to MIRRORS. Cross urls are supported, so its possible to mirror a git repository on an http server as a tarball for example. Some example commonly used mirror definitions are:</para>
375
376 <para><screen><varname>PREMIRRORS</varname> ?= "\
377bzr://.*/.* http://somemirror.org/sources/ \n \
378cvs://.*/.* http://somemirror.org/sources/ \n \
379git://.*/.* http://somemirror.org/sources/ \n \
380hg://.*/.* http://somemirror.org/sources/ \n \
381osc://.*/.* http://somemirror.org/sources/ \n \
382p4://.*/.* http://somemirror.org/sources/ \n \
383svk://.*/.* http://somemirror.org/sources/ \n \
384svn://.*/.* http://somemirror.org/sources/ \n"
385
386<varname>MIRRORS</varname> =+ "\
387ftp://.*/.* http://somemirror.org/sources/ \n \
388http://.*/.* http://somemirror.org/sources/ \n \
389https://.*/.* http://somemirror.org/sources/ \n"</screen></para>
390
391 <para>Non-local downloaded output is placed into the directory specified by the <varname>DL_DIR</varname>. For non local downloads the code can check checksums for the download to ensure the file has been downloaded correctly. These are specified in the form <varname>SRC_URI[md5sum]</varname> for the md5 checksum and <varname>SRC_URI[sha256sum]</varname> for the sha256 checksum. If <varname>BB_STRICT_CHECKSUM</varname> is set, any download without a checksum will trigger an error message. In cases where multiple files are listed in SRC_URI, the name parameter is used assign names to the urls and these are then specified in the checksums in the form SRC_URI[name.sha256sum].</para>
392
304 </section> 393 </section>
305 394
306 <section> 395 <section>
307 <title>Local file fetcher</title> 396 <title>Local file fetcher</title>
308 <para>The URN for the local file fetcher is <emphasis>file</emphasis>. The filename can be either absolute or relative. If the filename is relative, <varname>FILESPATH</varname> and <varname>FILESDIR</varname> will be used to find the appropriate relative file, depending on the <varname>OVERRIDES</varname>. Single files and complete directories can be specified. 397 <para>The URN for the local file fetcher is <emphasis>file</emphasis>. The filename can be either absolute or relative. If the filename is relative, <varname>FILESPATH</varname> and failing that <varname>FILESDIR</varname> will be used to find the appropriate relative file. The metadata usually extend these variables to include variations of the values in <varname>OVERRIDES</varname>. Single files and complete directories can be specified.
309<screen><varname>SRC_URI</varname>= "file://relativefile.patch" 398<screen><varname>SRC_URI</varname>= "file://relativefile.patch"
310<varname>SRC_URI</varname>= "file://relativefile.patch;this=ignored" 399<varname>SRC_URI</varname>= "file://relativefile.patch;this=ignored"
311<varname>SRC_URI</varname>= "file:///Users/ich/very_important_software" 400<varname>SRC_URI</varname>= "file:///Users/ich/very_important_software"
@@ -314,8 +403,8 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
314 </section> 403 </section>
315 404
316 <section> 405 <section>
317 <title>CVS file fetcher</title> 406 <title>CVS fetcher</title>
318 <para>The URN for the CVS fetcher is <emphasis>cvs</emphasis>. This fetcher honors the variables <varname>DL_DIR</varname>, <varname>SRCDATE</varname>, <varname>FETCHCOMMAND_cvs</varname>, <varname>UPDATECOMMAND_cvs</varname>. <varname>DL_DIR</varname> specifies where a temporary checkout is saved. <varname>SRCDATE</varname> specifies which date to use when doing the fetching (the special value of "now" will cause the checkout to be updated on every build). <varname>FETCHCOMMAND</varname> and <varname>UPDATECOMMAND</varname> specify which executables to use for the CVS checkout or update. 407 <para>The URN for the CVS fetcher is <emphasis>cvs</emphasis>. This fetcher honors the variables <varname>CVSDIR</varname>, <varname>SRCDATE</varname>, <varname>FETCHCOMMAND_cvs</varname>, <varname>UPDATECOMMAND_cvs</varname>. <varname>DL_DIR</varname> specifies where a temporary checkout is saved. <varname>SRCDATE</varname> specifies which date to use when doing the fetching (the special value of "now" will cause the checkout to be updated on every build). <varname>FETCHCOMMAND</varname> and <varname>UPDATECOMMAND</varname> specify which executables to use for the CVS checkout or update.
319 </para> 408 </para>
320 <para>The supported parameters are <varname>module</varname>, <varname>tag</varname>, <varname>date</varname>, <varname>method</varname>, <varname>localdir</varname>, <varname>rsh</varname> and <varname>scmdata</varname>. The <varname>module</varname> specifies which module to check out, the <varname>tag</varname> describes which CVS TAG should be used for the checkout. By default the TAG is empty. A <varname>date</varname> can be specified to override the SRCDATE of the configuration to checkout a specific date. The special value of "now" will cause the checkout to be updated on every build.<varname>method</varname> is by default <emphasis>pserver</emphasis>. If <emphasis>ext</emphasis> is used the <varname>rsh</varname> parameter will be evaluated and <varname>CVS_RSH</varname> will be set. Finally, <varname>localdir</varname> is used to checkout into a special directory relative to <varname>CVSDIR</varname>. 409 <para>The supported parameters are <varname>module</varname>, <varname>tag</varname>, <varname>date</varname>, <varname>method</varname>, <varname>localdir</varname>, <varname>rsh</varname> and <varname>scmdata</varname>. The <varname>module</varname> specifies which module to check out, the <varname>tag</varname> describes which CVS TAG should be used for the checkout. By default the TAG is empty. A <varname>date</varname> can be specified to override the SRCDATE of the configuration to checkout a specific date. The special value of "now" will cause the checkout to be updated on every build.<varname>method</varname> is by default <emphasis>pserver</emphasis>. If <emphasis>ext</emphasis> is used the <varname>rsh</varname> parameter will be evaluated and <varname>CVS_RSH</varname> will be set. Finally, <varname>localdir</varname> is used to checkout into a special directory relative to <varname>CVSDIR</varname>.
321 410
@@ -327,28 +416,19 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
327 416
328 <section> 417 <section>
329 <title>HTTP/FTP fetcher</title> 418 <title>HTTP/FTP fetcher</title>
330 <para>The URNs for the HTTP/FTP fetcher are <emphasis>http</emphasis>, <emphasis>https</emphasis> and <emphasis>ftp</emphasis>. This fetcher honors the variables <varname>DL_DIR</varname>, <varname>FETCHCOMMAND_wget</varname>, <varname>PREMIRRORS</varname>, <varname>MIRRORS</varname>. The <varname>DL_DIR</varname> defines where to store the fetched file. <varname>FETCHCOMMAND</varname> contains the command used for fetching. <quote>${URI}</quote> and <quote>${FILES}</quote> will be replaced by the URI and basename of the file to be fetched. <varname>PREMIRRORS</varname> will be tried first when fetching a file. If that fails, the actual file will be tried and finally all <varname>MIRRORS</varname> will be tried. 419 <para>The URNs for the HTTP/FTP fetcher are <emphasis>http</emphasis>, <emphasis>https</emphasis> and <emphasis>ftp</emphasis>. This fetcher honors the variables <varname>FETCHCOMMAND_wget</varname>. <varname>FETCHCOMMAND</varname> contains the command used for fetching. <quote>${URI}</quote> and <quote>${FILES}</quote> will be replaced by the URI and basename of the file to be fetched.
331 </para>
332 <para>The only supported parameter is <varname>md5sum</varname>. After a fetch the <varname>md5sum</varname> of the file will be calculated and the two sums will be compared.
333 </para> 420 </para>
334 <para><screen><varname>SRC_URI</varname> = "http://oe.handhelds.org/not_there.aac;md5sum=12343" 421 <para><screen><varname>SRC_URI</varname> = "http://oe.handhelds.org/not_there.aac"
335<varname>SRC_URI</varname> = "ftp://oe.handhelds.org/not_there_as_well.aac;md5sum=1234" 422<varname>SRC_URI</varname> = "ftp://oe.handhelds.org/not_there_as_well.aac"
336<varname>SRC_URI</varname> = "ftp://you@oe.handheld.sorg/home/you/secret.plan;md5sum=1234" 423<varname>SRC_URI</varname> = "ftp://you@oe.handheld.sorg/home/you/secret.plan"
337</screen></para> 424</screen></para>
338 </section> 425 </section>
339 426
340 <section> 427 <section>
341 <title>SVK fetcher</title>
342 <para>
343 <emphasis>Currently NOT supported</emphasis>
344 </para>
345 </section>
346
347 <section>
348 <title>SVN fetcher</title> 428 <title>SVN fetcher</title>
349 <para>The URN for the SVN fetcher is <emphasis>svn</emphasis>. 429 <para>The URN for the SVN fetcher is <emphasis>svn</emphasis>.
350 </para> 430 </para>
351 <para>This fetcher honors the variables <varname>FETCHCOMMAND_svn</varname>, <varname>DL_DIR</varname>, <varname>SRCDATE</varname>. <varname>FETCHCOMMAND</varname> contains the subversion command. <varname>DL_DIR</varname> is the directory where tarballs will be saved. <varname>SRCDATE</varname> specifies which date to use when doing the fetching (the special value of "now" will cause the checkout to be updated on every build). 431 <para>This fetcher honors the variables <varname>FETCHCOMMAND_svn</varname>, <varname>SVNDIR</varname>, <varname>SRCREV</varname>. <varname>FETCHCOMMAND</varname> contains the subversion command. <varname>SRCREV</varname> specifies which revision to use when doing the fetching.
352 </para> 432 </para>
353 <para>The supported parameters are <varname>proto</varname>, <varname>rev</varname> and <varname>scmdata</varname>. <varname>proto</varname> is the Subversion protocol, <varname>rev</varname> is the Subversion revision. If <varname>scmdata</varname> is set to <quote>keep</quote>, the <quote>.svn</quote> directories will be available during compile-time. 433 <para>The supported parameters are <varname>proto</varname>, <varname>rev</varname> and <varname>scmdata</varname>. <varname>proto</varname> is the Subversion protocol, <varname>rev</varname> is the Subversion revision. If <varname>scmdata</varname> is set to <quote>keep</quote>, the <quote>.svn</quote> directories will be available during compile-time.
354 </para> 434 </para>
@@ -361,7 +441,7 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
361 <title>GIT fetcher</title> 441 <title>GIT fetcher</title>
362 <para>The URN for the GIT Fetcher is <emphasis>git</emphasis>. 442 <para>The URN for the GIT Fetcher is <emphasis>git</emphasis>.
363 </para> 443 </para>
364 <para>The Variables <varname>DL_DIR</varname>, <varname>GITDIR</varname> are used. <varname>DL_DIR</varname> will be used to store the checkedout version. <varname>GITDIR</varname> will be used as the base directory where the git tree is cloned to. 444 <para>The variable <varname>GITDIR</varname> will be used as the base directory where the git tree is cloned to.
365 </para> 445 </para>
366 <para>The parameters are <emphasis>tag</emphasis>, <emphasis>protocol</emphasis> and <emphasis>scmdata</emphasis>. <emphasis>tag</emphasis> is a Git tag, the default is <quote>master</quote>. <emphasis>protocol</emphasis> is the Git protocol to use and defaults to <quote>rsync</quote>. If <emphasis>scmdata</emphasis> is set to <quote>keep</quote>, the <quote>.git</quote> directory will be available during compile-time. 446 <para>The parameters are <emphasis>tag</emphasis>, <emphasis>protocol</emphasis> and <emphasis>scmdata</emphasis>. <emphasis>tag</emphasis> is a Git tag, the default is <quote>master</quote>. <emphasis>protocol</emphasis> is the Git protocol to use and defaults to <quote>rsync</quote>. If <emphasis>scmdata</emphasis> is set to <quote>keep</quote>, the <quote>.git</quote> directory will be available during compile-time.
367 </para> 447 </para>