From: Hans Beckerus <hans.beckerus@gmail.com>
To: Robert Calhoun <rcalhoun@shotspotter.com>,
Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: SRCREV how is it supposed to work?
Date: Tue, 05 Nov 2013 23:21:53 +0100 [thread overview]
Message-ID: <52796F81.6010900@gmail.com> (raw)
In-Reply-To: <CE9EC8E7.1E1933%rcalhoun@shotspotter.com>
On 2013-11-05 11:10, Robert Calhoun wrote:
> -----Original Message-----
> From: Paul Eggleton <paul.eggleton@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:
A good example indeed. I will see what I can make out of it in our own recipes.
I also realized the caveats attached to finding the patch dir etc. when auto-incrementing the version.
This will certainly help.
Thanks.
Hans
> -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
>
>
>
>
prev parent reply other threads:[~2013-11-05 22:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 11:46 SRCREV how is it supposed to work? Hans Beckérus
2013-10-29 11:00 ` Martin Jansa
2013-10-29 13:27 ` Hans Beckérus
2013-10-29 13:42 ` Martin Jansa
2013-10-29 14:20 ` Hans Beckérus
2013-11-05 9:25 ` Hans Beckérus
2013-11-05 9:47 ` [meta-mono] Mono 3.2.3 support Alex J Lennon
2013-11-05 10:51 ` SRCREV how is it supposed to work? Paul Eggleton
2013-11-05 22:10 ` Robert Calhoun
2013-11-05 22:21 ` Hans Beckerus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52796F81.6010900@gmail.com \
--to=hans.beckerus@gmail.com \
--cc=paul.eggleton@linux.intel.com \
--cc=rcalhoun@shotspotter.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.