rather than let this dribble out section by section, here's my
collection of observations on the entire file download section of the
bitbake manual. there are a number of picky grammatical issues and
i'll ignore those, there are bigger fish to fry.
overview:
========
might sound geeky but i think it's worth pointing the reader at the
lib/bb/fetch directory if they're interested in the actual
implementation.
also, for explanatory power, i think it's important to support each
fetcher section with a *comprehensive* list of examples that show
most, if not all, of the variations that that fetcher supports. more
on this shortly.
local file fetcher:
==================
looks all right, except i'd adjust all examples there to use
"SRC_URI =", not "SRC_URI=", since the latter occurs nowhere in the OE
tree, for example. and i think this is important, since what i'm
doing to understand these fetchers is grep'ping through the OE tree
for all uses, which means that examples should match *verbatim* their
use in a sample metadata tree like OE so that grepping works.
i would also mention that this is supported by the local.py python
script.
cvs file fetcher:
================
mention that this is supported by cvs.py. also, that list of
supported parameters is missing 'port', which i noticed simply by
reading the source.
now, what's with "CVSDATE"? the manual makes no mention of it, yet
it's tested in __init__.py. and most instances in the OE tree use
SRCDATE for cvs, not CVSDATE, even though there are a few exceptions:
$ grep -rw CVSDATE *
contrib/qa/bugzilla.py: <td>OE build of u_boot with CVSDATE 20061030 uses
latest git ...
contrib/oe-stylize.py: 'CVSDATE',
docs/usermanual/embworld-oe.dbk:# builds this fetches the same source, use
CVSDATE.
docs/usermanual/embworld-oe.dbk:CVSDATE = "20051122"
recipes/nylon/nylon-config.bb:CVSDATE = "20051026"
recipes/nylon/nylon-config.bb:PV = "cvs${CVSDATE}"
$
so, for cvs, is it CVSDATE? or SRCDATE? or either? or perhaps
standardize on one and remove the other?
and i notice in a number of recipes the use of FIXEDSRCDATE. should
that also not be documented? whatever it means.
http/ftp fetcher:
================
mention that this is implemented in wget.py, and fix an issue or two
on that page. i believe the reference to ${FILES} should actually be
just ${FILE}, no? at least according to wget.py.
also, that page reads:
"The only supported Parameter is md5sum." well, no, it also supports
"name," which seems pretty important to mention and explain.
in addition, that section should certainly mention that the argument
can be a multi-file value, as in:
SRC_URI =
"http://www.packagekit.org/releases/PackageKit-${PV}.tar.gz;name=archive \
file://configurefix.patch \
file://opkgfixes.patch"
otherwise, readers might have no idea that that's possible. as i
mentioned before, every one of these fetchers should be explained with
a comprehensive list of examples showing its variations.
svk fetcher:
===========
since this is unlikely to ever be supported, why not just drop this
section and the bitbake support for it?
svn fetcher:
===========
supported by svn.py, and here's where it gets weird:
"This Fetcher honors the variables FETCHCOMMAND_svn ..."
um, no ... svn.py uses "FETCHCMD", which suddenly reveals the
inconsistency across fetcher variables:
$ grep FETCH *
bzr.py: basecmd = data.expand('${FETCHCMD_bzr}', d)
cvs.py: cvscmd = data.getVar('FETCHCOMMAND', localdata, 1)
git.py: ud.basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
git.py: basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
git.py: basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
hg.py: basecmd = data.expand('${FETCHCMD_hg}', d)
osc.py: basecmd = data.expand('${FETCHCMD_osc}', d)
perforce.py: p4cmd = data.getVar('FETCHCOMMAND_p4', d, 1)
perforce.py: p4cmd = data.getVar('FETCHCOMMAND', localdata, 1)
svn.py: basecmd = data.expand('${FETCHCMD_svn}', d)
wget.py: fetchcmd = data.getVar("FETCHCOMMAND", d, 1)
$
why are some FETCHCMD while others are FETCHCOMMAND? that seems
unnecessarily confusing. then i see in OE:
$ grep -r "FETCH.*_svn" *
conf/bitbake.conf:FETCHCMD_svn = "/usr/bin/env svn"
conf/bitbake.conf:FETCHCOMMAND_svn = "/usr/bin/env svn co ${SVNCOOPTS}
${SVNROOT} ${SVNMODULE}"
$
and now i'm confused, since that manual page also refers to just
"FETCHCOMMAND."
also, on that manual page:
"The supported Parameters are proto, rev. proto is the subversion
prototype, rev is the subversions revision."
but "module" and "date" are also supported, are they not?
finally, that manual page refers to the variable SRCDATE. however,
__init__.py refers to something called "CVSDATE". is that valid as
well, since it's not mentioned? it does show up a wee bit in the OE
tree:
$ grep -rw CVSDATE *
contrib/qa/bugzilla.py: <td>OE build of u_boot with CVSDATE 20061030 uses
latest git ...
contrib/oe-stylize.py: 'CVSDATE',
docs/usermanual/embworld-oe.dbk:# builds this fetches the same source, use
CVSDATE.
docs/usermanual/embworld-oe.dbk:CVSDATE = "20051122"
recipes/nylon/nylon-config.bb:CVSDATE = "20051026"
recipes/nylon/nylon-config.bb:PV = "cvs${CVSDATE}"
$
and the OE tree also refers to something called "FIXEDSRCDATE" quite
a lot in the context of cvs fetching. totally confusing.
git fetcher:
===========
supported by git.py. there is no mention that that fetcher
recognizes the variable FETCHCMD_git, but i don't see it being
used anywhere throughtout OE. is it actually useful?
i also see git.py referring to BB_GENERATE_MIRROR_TARBALLS but,
again, i see no use of it anywhere in the OE tree. does it have any
value?
and, as with the other fetchers, i think it's worth showing a
multi-line example of this, as in:
SRC_URI = "git://github.com/tias/xinput_calibrator.git;protocol=git \
file://xinput-calibrator.desktop \
file://xinput_calibrator_once.sh \
oh, and i see that git.py tests a variable called
BB_GIT_CLONE_FOR_SRCREV, but i see no use of it anywhere in OE. is it
actually being used anywhere?
=== the end ===
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
