[yocto] SRCREV how is it supposed to work?

[Robert Calhoun]

-----Original Message-----
From: Paul Eggleton <paul.eggleton at linux.intel.com>
>
>AFAIK, there are two recommended values for SRCREV assuming you are
>fetching 
>from an SCM at all:
>
>A) A specific revision (SHA1 hash when fetching from git)
>
>or
>
>B) "${AUTOREV}" if you want to always build the latest version available
>at 
>time of building. If you want to build the latest version from a branch,
>specify it in branch= in the SRC_URI entry.
>
>Anything else isn't really a good idea. Sometimes I wonder if we ought to
>just 
>tighten this up so that only settings that make sense can be set.

The current behavior is a little non-intuitive, since using SRCREV =
"${AUTOREV}" 
alone will not force the package to be rebuilt when SRCREV changes. Unless
I am
mistaken, $PV needs to be modified also. But modifying $PV causes its own
headaches with patching, so I've ended up using recipes based on the model
below.

Another challenge is that bitbake's fetch2 is not very well documented. I
don't
think the "user" and "pswd" fields for the svn fetcher are documented
anywhere
outside of the source code.

I'd love to help address this, but I'm not sure where I should submit
updated documentation. Is this the right place?

git://git.yoctoproject.org/yocto-docs


Hans, below is a model recipe for building current head-of-line from a
subversion repository:

-Rob Calhoun
SST Inc
 



######################

DESCRIPTION = "example_1.0.bb, autorevving checkout example"

# This says look for LICENSE in the root of the directory being checked
out. Fix
# license filename and md5sum as required.
LIC_FILES_CHKSUM = "file://LICENSE;md5=abc123"

# this is the rev of your recipe. Bumping it will toss the cache and redo
everything
PR = "r1"

# pick up latest svn rev for this module. Note this a deferred evaluation!
SRCREV = "${AUTOREV}"

# ${PV} is pulled from the recipe filename, e.g. helloworld_2.7.bb ->
${PV} expands to "2.7".
# We use immediate evaluation to define a new var PVBASE holding the
original value of ${PV}.
PVBASE := "${PV}"

# We need to tell bitbake about our current directory structure or we
won't be able to find patches after we mess with ${PV}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PVBASE}:"

# Then redefine PV to tack the svn rev onto the base version. This is
evaluated at fetch time.
# Then the package will get rebuilt any time the relevant part of the
source tree changes.
PV = "${PVBASE}.${SRCPV}"

# Now we format the source code URI.
# There is nothing special about "module"; it is just the final directory
of the svn checkout.
# SRC_URI below is equivalent to the svn command:
# "svn checkout --username=poky --password=xyzzy
https://svn.example.com/repo/trunk/example"
#
SRC_URI= 
"svn://svn.example.com/repo/trunk;module=example;protocol=https;user=poky;p
swd=xyzzy"

# build will fail without this; it specifies where in the workdir to find
the source. The
# name must be the same as the "module" name in SRC_URI.
S = "${WORKDIR}/example"

# BELOW NOT PART OF RECIPE; IT SHOWS WHAT THE WORK DIR LOOKS LIKE WITH
THIS RECIPE.
# By setting PV, the cache is invalidated and new code checked out each
time the 
# relevant part oF the svn repo gets updated because I've made the svn
revision look
# like a package version number to bitbake.
#
# Here is a directory listing of the work dir:
#
# 
poky at build:/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/example$
 ls -l
#drwxrwxr-x 12 poky poky 4096 Oct 30 10:17 1.0.57400-r1
#drwxrwxr-x 12 poky poky 4096 Oct 30 11:52 1.0.57401-r1
#drwxrwxr-x 12 poky poky 4096 Oct 31 12:37 1.0.57408-r1
#drwxrwxr-x 12 poky poky 4096 Nov  1 07:56 1.0.57412-r1