From: Martin Jansa <martin.jansa@gmail.com>
To: Brad Litterell <brad@evidence.com>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
"yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: Setting PV dynamically in a recipe
Date: Wed, 18 Dec 2013 10:36:24 +0100 [thread overview]
Message-ID: <20131218093624.GK3706@jama> (raw)
In-Reply-To: <E51394554A503C4E852F9BEE46B03E8D019AC9AE@TI-THOR.tasernet.com>
[-- Attachment #1: Type: text/plain, Size: 3369 bytes --]
On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> Hi Paul,
>
> Thanks for that tip. For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
>
> In an ideal world, I'd like to to be able to build in two modes: dev & release. Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc. (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
>
> What is the best way to switch recipes between dev & test modes like that. It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
>
> SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
>
> or whether something like that is asking for trouble. My current solution is manual - edit the recipe, but that feels kinda lame.
>
> It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
>
> Any suggestions?
Don't use *IMAGE_FEATURES* to in recipe conditionals.
When you're building some package you don't know in which image it will
be included so you cannot know with which *IMAGE_FEATURES* it should be
built.
It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
still it's unsafe to assume they are "global". With improved
base_contains and sstate interaction, using some flag in DISTRO_FEATURES
shouldn't cause so many packages to rebuild, so it could be usable for
"debug-build" flag.
> ________________________________________
> From: Paul Eggleton [paul.eggleton@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> Hi Brad,
>
> On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > Thank you for the reply. However, That's not what I'm looking for. I
> > already get the latest version of the source code.
> >
> > What I'm really after is the ability to generate output packages that have
> > increasing version numbers so I can use the package manager to update them.
> >
> > I think Martin's subsequent reply is the secret to use PKGV. I didn't know
> > about that variable.
>
> You don't need to use any special classes to get this behaviour. Put this in
> your recipe (replacing 1.2.3 with the appropriate base version you are
> building):
>
> PV = "1.2.3+git${SRCPV}"
>
> and enable the PR service, which will ensure SRCREV changes always increment
> the version properly:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2013-12-18 9:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-17 8:16 Setting PV dynamically in a recipe Brad Litterell
2013-12-17 9:41 ` zhenhua.luo
2013-12-17 19:46 ` Brad Litterell
2013-12-17 20:24 ` Paul Eggleton
2013-12-18 1:29 ` Brad Litterell
2013-12-18 9:36 ` Martin Jansa [this message]
2013-12-20 3:09 ` Brad Litterell
2013-12-20 9:34 ` Martin Jansa
2013-12-20 9:39 ` Brad Litterell
2013-12-20 10:01 ` Martin Jansa
2013-12-20 10:03 ` Brad Litterell
2013-12-20 10:11 ` Brad Litterell
2013-12-20 11:26 ` Martin Jansa
2013-12-17 14:01 ` Martin Jansa
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=20131218093624.GK3706@jama \
--to=martin.jansa@gmail.com \
--cc=brad@evidence.com \
--cc=paul.eggleton@linux.intel.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.