After some effort, I believe I have a working BitBake recipe for
cross-compiling fossil in an embedded Linux distribution built by the
Yocto Project's BitBake tool. While getting this to work, I've also
noticed that the documentation for the /zip and /tarball pages could be
better.
All in all, this was not hard to do. BitBake is intended exactly for
this task. Namely, a recipe can specify the URL of a tarball which it
will fetch, unpack, and build. Along the way, it collects licenses for
the things it builds, verifies that files it downloaded have the
expected checksums, handles the frequent need to apply locally developed
patches to packages obtained from upstream sources, and similar
configuration management tasks.
While BitBake has some built-in understanding of Git and Hg (apparently
it can use their native protocols to do some clever things), it does not
have any special awareness of fossil. However, it does allow a zip or
tarball to be fetched from an arbitrary URL, and it has no problems if
that URL happens to contain CGI parameters, so it actually can fetch a
tarball for a specific checkin (or tagged release, or some branch, or
...) directly from fossil-scm.org.
Strong conventions within the Yocto project appear to dictate that the
tarball for fossil version 1.29 should be named fossil-1.29.tgz, which
holds a single folder named fossil-1.29 in which the source kit resides.
From experimentation, staring at the source code, and reading
documentation it appears there is more than one way to construct an URL
that fetches the same suitable tarball:
<repo>/tarball/fossil-1.29.tgz?uuid=version-1.29
<repo>/tarball/ignored?name=fossil-1.29.tgz&uuid=version-1.29
<repo>/tarball?name=fossil-1.29.tgz&uuid=version-1.29
(<repo> is http://fossil-scm.org/index.html in this case.) Also,
substituting uuid=3e5ebe2b90 (or any unambiguous prefix of the full
hash) will also get the same tarball, unless the tag "version-1.29" is
moved to a newer checkin.
However, the documentation at
http://www.fossil-scm.org/fossil/help?cmd=/tarball is somewhat
confusing. It reads in full:
URL: /tarball/RID.tar.gz
Generate a compressed tarball for a checkin.
Return that tarball as the HTTP reply content.
Optional URL Parameters:
- name=base name of the output file. Defaults to
something project/version-specific.
- uuid=the version to tar (may be a tag/branch name).
Defaults to trunk.
None of the forms I listed above that retrieved a tarball for a specific
checkin or tag match all of the details. In context, one might expect
"RID.tar.gz" to be an RID with a suffix. But various attempts to put a
checkin UUID in that position retrieved a well-formed tarball containing
some other checkin. In short, it appears that a better description is
"/tarball/NAME.tar.gz" which is a synonym for
"/tarball?name=NAME.tar.gz". That parameter is only the basename of the
file in the context of a browser that uses the last path component as
the file name. It is, however, used as the top level folder name inside
the tarball, after the .tar.gz (or .tgz or similar shorter extension) is
stripped off.
I think editing the help text to be more like this would bring it more
in line with what appears to be implemented.
URL: /tarball/FOLDER.tar.gz
Generate a compressed tarball for the tip of trunk, or
optionally any other checkin. Return that tarball as the
HTTP reply content.
Optional URL Parameters:
- name=FOLDER.tar.gz After stripping the extension, the
remainder the names the top level folder inside the
tarball.
- uuid=the version to tar which may be a tag or branch
name. Defaults to "trunk".
Naturally, the descriptions of the /zip URL as well as the fossil
tarball and fossil zip commands should be aligned as well.
Putting this all together, any BitBake recipe can refer to a specific
checkin of a project in a fossil repository that is available via HTTP
to the machine running BitBake with a reference like:
SRC_URI = "http://example.com/cgi-bin/repo/project/tarball\
?name=${PN}-${PV}.tgz\
&uuid=version-1.42.0-p13\
;downloadfilename=${PN}-${PV}.tgz"
SRC_URI[md5sum]="----MD5 of the tarball----"
SRC_URI[sha256sum]="----SHA256 of the tarball ----"
This constructs the URL to fetch from the PN and PV strings which
BitBake provides as a package name and package version. It also uses the
extra parameter ";downloadfilename=" to cause BitBake to tell wget what
to name the file it saves. Without that, the saved tarball will include
all the URL parameters and be rather difficult to refer to with '?' and
'&' characters in it.
Although BitBake won't proceed past a download without the checksums
matching, don't worry too hard about getting the MD5 and SHA256 in
advance. BitBake's error message happens to include text you can copy
and paste to the recipe.
After that, the rest of the recipe will follow the usual conventions
depending on how your project is built.
I'll post my recipe for building fossil itself separately, after I've
verified that the fossil it builds actually does run in my target hardware.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
