[oe] [bitbake-devel] source folder package dependency
Paul Eggleton
paul.eggleton at linux.intel.com
Wed Feb 1 15:37:08 UTC 2012
On Monday 30 January 2012 18:40:03 Aleh Arol wrote:
> I have a question I don't know how to solve:
> I have a library, for example, boost, and a part of that
> library(packaged together I mean), like bjam is required to build it.
>
> So I have boost-X.Y.Z.bb recipe and src/boost-X.Y.Z folder(I have
> sources locally) and I need to create bjam recipe. I can make
> bjam-X.Y.Z.bb where I will refer to folder src/boost-${PV} as ${SRC_URI}
> and ${S} to find jam sources under. Then if I'll need to have 5
> different versions of boost I'll need to create 5 different versions of
> bjam recipe.... although I can use bjam.inc it will still be 5 bjam recipes.
>
> How can I avoid that? Any way to have a version agnostic bjam recipe? Or the
> right way of doing this.
(I presume this is in the context of OpenEmbedded.) What you describe is the
accepted way of doing things - you have a recipe for each version of the piece
of software you're building and share the common things with a .inc file, using
${PV} to abstract away the version. Each individual recipe ends up quite small
with the bulk of the definitions in the inc file.
You could have a recipe which did not specify a version in the recipe filename,
and set PV manually instead (possibly with a default); then you could set
PV_pn-bjam = "1.1" in your distro or local configuration to pick the version.
However I would describe that as unorthodox, and it will not work if you have
to handle other differences between versions (e.g. renamed/moved files,
additional configuration options, etc.) I will say however that this is more or
less how we handle recipes built from a version control system (e.g. git);
except in that case we set PV to something including SRCREV e.g.
"1.0+gitr${SRCPV}" and then set SRCREV externally.
The question is will you really need 5 different versions? Or just 2-3?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-devel
mailing list