-----Original Message----- From: Paul Eggleton <paul.eggle...@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@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto